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SECTION 1 
INTRODUCTION 


For the nation to embark on a robust space program which includes the deployment 
and operation of the Space Station Freedom (SSF), the human transportation 
function to and from low Earth orbit (LEO) over the next several decades will have 
to be accomplished routinely, affordably, reliably, and safely. Currently, the United 
States relies on the Space Shuttle to provide its human transportation needs, as well 
as the bulk of its cargo transportation needs. However, over the past several years, 
there have been numerous system concept development efforts investigating what 
the next human transportation system might be. Some of these alternative 
transportation architectures take as their underlying premise the replacement of the 
Space Shuttle orbiters at the end of some useful lifetime. Other alternative 
scenarios assume that it is more expedient to evolve the Space Shuttle, 
recommending modifications that range anywhere from minor to substantial. Still 
other alternative scenarios assume the eventual replacement of the Space Shuttle 
with other concepts which rely extensively on the use of advanced technology. Yet 
other scenarios have been constructed which involve augmenting the Space Shuttle 
with another independent transportation system to achieve "assured access." 

As could be expected, these divergent, underlying, initial assumptions about the 
fundamental purpose of a new vehicle have given rise to widely disparate system 
concepts for the next human transportation system. For example, the NASA 
Langley Research Center is currently studying the characteristics of a horizontal 
lifting body vehicle, designated the HL-20, as a personnel carrier. Its primary 
mission is to support crew rotation to and from the SSF. The Johnson Space Center 
(JSC) also investigated personnel carriers for this same reference mission, focusing 
primarily on biconic shapes. These concepts only address the transportation of the 
crew and do not include any provision for the transportation of cargo. Other 
concepts, such as the Crew and Logistics Vehicle (CLV), have been developed which 
include a small amount of cargo on the personnel carrier. Several system concepts 
have also been proposed that are based on evolving the Space Shuttle by 
incorporating increased safety and performance features, while retaining the ability 
to carry cargo. The Advanced Manned Launch System (AMLS), Single-Stage-to- 
Orbit (SSTO), and the National Aerospace Plane (NASP) are concepts which have 
been developed by those who believe that technological advances may offer 
significant savings in operations costs by routinely achieving high flight rates. In 
addition, conventional approaches such as launching small personnel carriers on 
top of an expendable launch vehicle and more unconventional approaches where 
the personnel carriers are mated to an air-launched booster, have also been 
considered. Many of these system concepts could be used to provide alternate access 
to the Space Shuttle. 

Recognizing that limited resources will be available to accomplish the activities 
required for missions to and from Planet Earth, the JSC, as the agency's lead for 
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piloted vehicles, initiated this study under the sponsorship of NASA Headquarters, 
Advanced Program Development Division. The purpose of this study was to 
address the need and urgency for any next human transportation system, and 
develop the decision materials to determine what the next human transportation 
system should be. A large portion of the data for this study came from the 
abundant, available technical information about various, alternative concepts that 
have been developed in recent study and design efforts across the country. 

1.1 Study Background 

A fundamental tenet of the Human Transportation System (HTS) study was that 
products and recommendations should be based on consistent and applicable 
mission models, requirements, and attributes. Although several architecture 
studies have been conducted over the past 7 years, they have not produced a clear 
consensus on the results, for precisely this reason. These previous studies were the 
Space Transportation Architecture Study (STAS), the Space Transportation 
Infrastructure Study (STIS), and the Next Manned Transportation System Study 
(NMTS). 

The STAS study was a combined effort of both NASA and the Department of 
Defense (DOD). Many of its recommendations led to the beginning of the Advanced 
Launch System (ALS) and the National Launch System (NLS) programs. However, 
the STAS study had mission models that showed much larger traffic models than 
are shown in the current NASA Civil Needs Database (CNDB). In some of the 
mission models, this was a reflection of the expected payload size, weight, and flight 
rate requirements for the Strategic Defense Initiative (SDI) at the time of the study 
(1985). The study also used cost as the only quantitative measurement of 
comparisons between systems. For example, safety of the crew was assumed to not 
be a discriminator, and therefore, was not a measured criterion. Since crew safety is 
always of primary concern, it should be considered quantitatively when comparing 
and defining transportation architectures. 

The NMTS study was conducted without NASA funding but with industry 
participation. The study did produce some enlightening data, however, since the 
industry participants used their own funding, each study had its own process and its 
own recommendations. There were no unified conclusions or recommendations. 

The STIS study has been used effectively for performing specific trade studies on a 
few possible transportation architectures. It can, for example, provide insight into 
the effect on the cost of using NLS to off-load the Space Shuttle, or assess the impacts 
of Earth-to-orbit (ETO) cargo carriers and transportation nodes on ETO transporta- 
tion in support of various Space Exploration Initiative (SEI) scenarios. It does, 
however, have a narrow focus (based on the number of ETO architectures compared 
to each other) and is not trying to evaluate all the impacts of architecture differences 
(safety, cost risk, reliability, etc.) that may be needed to truly judge (in the customer's 
eyes) one architecture relative to another. 
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While these studies did produce useful information, they did not develop rigorous 
and measurable evaluation criteria (attributes) to compare differing transportation 
architecture options. Moreover, many of the study assumptions (e.g., overly 
optimistic traffic models) made them untimely for answering questions currently 
being asked within the agency regarding future transportation strategies. To focus 
the agency's human transportation efforts and to achieve the desired products, this 
study was conceived with an objective to address the significant top-level 
architectural considerations prior to conducting additional individual system 
concept definition efforts. The HTS study approach examined the transportation 
needs of the country, defined those transportation system attributes desired by the 
customer, and evaluated various transportation architecture options against those 
needs and attributes. The study horizon was from the present to the year 2020. 
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SECTION 2 

STUDY APPROACH AND GROUND RULES 


From the beginning of the study, it was recognized that if some of the top-level 
architectural considerations were to be answered, it was essential to have access to 
the best data from previous concept design efforts. Also, since there was interest in 
determining just what convergence existed in the data, it was decided that the study 
approach should involve the best minds in the business, both in and out of the 
government. It was determined that a partnership between NASA and industry 
was essential, and hence the NASA-Industry Team (NIT) concept was formed. This 
approach involved six major aerospace firms working together with NASA to 
provide technical data to address the architectural considerations. These six firms 
were selected by competitive process through an agency-wide evaluation to 
participate in the NIT. These included Boeing, General Dynamics, Martin Marietta, 
Rockwell, Lockheed, and McDonnell Douglas. NASA centers working together to 
complete the NIT included JSC, Langley Research Center (LaRC), Marshall Space 
Flight Center (MSFC), Kennedy Space Center (KSC), as well as NASA Headquarters. 
The industry team members conducted their study efforts under contracts of $425K 
each, for a total of $2550K. 


2.1 STUDY APPROACH 

The study was divided into four tasks. The first two tasks involved determining the 
transportation needs and transportation attributes. This essentially formed the 
input requirements for the study. The third task was to evaluate the candidate 
architectures. The fourth task was an evaluation of NASA's current business 
practices which may be hindering, to some degree, the ability to develop, procure, 
and operate any next human transportation system. These four tasks are described 
in more detail in the following paragraphs. 


2.1.1 Task 1: Transportation Needs 

From the outset, it was felt that the mission of any next human transportation 
system must be understood in terms of the transportation jobs that it must 
accomplish. These jobs are the requirements which define what payloads need to be 
transported and when. This indicated a needs-based study approach, as opposed to a 
capabilities-based approach. Furthermore, the best solution for human 
transportation can not be developed without taking into consideration the 
transportation of cargo since optimization of the transportation attributes may 
require the use of commonality between the personnel and cargo transportation 
systems. In addition, addressing current national questions as to whether any new 
system was required as a replacement for the Space Shuttle, or whether a new 
system was required to operate in conjunction with the Space Shuttle to assure 
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human access to space, could only be answered by a needs-based approach. Finally, 
by taking a parametric look at the transportation needs as function of the major 
space activities, the study approach was able to accommodate the large uncertainty 
in the space agenda that the nation might eventually embark upon. Figure 2.1. 1-1 
illustrates how eight potential mission types were assembled into five levels of 
space activity to comprise the components of the parametric transportation needs 
model. This is the HTS "mission model." 


2.1.2 Task 2: Customer-Desired Transportation Attributes 

Attributes reflect what the customer considers important in the next human 
transportation system. These attributes are determined by placing ourselves in the 
customers shoes, and asking what factors would be considered in the decision- 
making process. These attributes are typically related to cost, safety, reliability, risk, 
etc. To be useful in a rigorous study, the definitions and measurements of these 
attributes had to be precisely established. Also, to quantitatively define the 
contribution of each individual attribute to the customer, utility functions, 
describing how important the value of each attribute was to the customer, were 
defined. 

The customer for the next human transportation system was determined to be that 
individual most responsible for (a) ensuring that die transportation needs are 
accomplished, (b) resolving what the total (human-tended and untended) 
transportation architecture should be, (c) determining how that architecture is 
implemented and operated, and (d) deciding how the total architecture is funded. It 
was the consensus of the study team that the NASA Administrator best fit this 
description. 


2.1.3 Task 3: Architecture Evaluation 

The results from Tasks 1 and 2 were used as inputs for Task 3. The ultimate 
objective of this task was to develop the system-level requirements on any indicated 
next transportation system. This was accomplished by first addressing the inevitable 
architectural considerations concerning how the next human transportation system 
relates to the other existing and planned programs which now provide some degree 
of the transportation function. The requirements that resulted from this task 
address the need and urgency for any next system(s), and provide "marks" for the 
safety, reliability, cost, etc. values that the next system should possess to be 
architecturally competitive. Addressing these requirements was best accomplished 
by defining a list of considerations to be investigated. These considerations 
included: 
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’V the range of expected space activity includes ... 
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• the degree of separation of people and cargo 

• the role of any new transportation system in relation to that of the Space Shuttle 

• assessing the cost-to-benefit of alternate access, that is having two methods to 
deliver and/or return people and cargo 

• commonality with or influence on the ACRV 

• evolution of current systems 

• the size and features of an expendable booster developed specifically from the 
outset with human transportation in mind 

• the benefit that could be realized by using transportation systems employing 
advanced technology approaches. 

To address these considerations, a set of approximately 20 architectures was 
constructed. An architecture is that set of transportation systems that accomplishes 
the transportation needs over some specified time frame. To be unique, an 
architecture must include the introduction dates of new systems and retirement 
dates of old systems, numbers of expendable vehicles, fleet size for reusable vehicles, 
and the supporting ground infrastructure supporting the flight systems. Evaluation 
of the attribute values for these architectures as they perform the different levels of 
space activity provides valuable target values for future systems to achieve if they 
are to accomplish improvements over the current systems they are replacing. 

It was recognized early in the study that an automated decision support tool would 
be required to manipulate the large volume of data generated in support of the 
evaluation process. In addition, the use of an automated tool would allow 
sensitivity analyses on the relative weights of the attributes and their associated 
utility functions to be conducted. Finally, an automated tool would allow the 
architecture performance assessment across six levels of space activity to be confined 
to the last months of the study, thereby allowing maximum time for the 
development and collection of quality data from the team members. An automated 
tool would also facilitate updating the results of the study in subsequent years, 
should that be required. 


2.1.4 Task 4: New Ways of Doing Business Better 

The way transportation system elements are procured, managed, designed, and 
operated has a significant bearing on their ability to provide routine, affordable, 
reliable, and safe transportation. The objective of this task was to identify any new 
ways of doing the future transportation business that would result in more 
favorable values of the transportation attributes. Most of the effort associated with 
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this task was directed at reducing the costs of ownership. The ultimate intent of this 
activity was to identify current barriers to lower ownership costs so that manage- 
ment could develop subsequent plans for their removal and so that the most 
significant of these findings could be implemented at the conclusion of the study. 

he data from this activity was developed by interviewing top program and project 
managers within industry and government, who were requested to provide their 
mS «° those organization, management, policy and procedures, and funding 
and budget practices that, if done differently, would result in the largest 
improvement in transportation system costs. 

Figure 2.1.4 shows the study schedule. The team members were in residence at TSC 
for the entire first month of the study. One benefit of being together for the entire 
month was that the team better understood the strengths that each member brought 
to the study both organizationally as well as personally. During that time, the team 
e med the detailed study approach jointly with the government so that all team 
members had ownership not only of the study intent, but also of the process by 
which the study was to be conducted. The team then spent the remainder of that 
first month m concentrated work sessions, developing both the transportation 
needs, i.e., what had to be transported to and from space and when, and the 
important attributes of the transportation architecture. Three week-long meetings 
where held over the next 5 months to define systems, architectures, and associated 
manifesting philosophy, to refine the study flow as needed, and to divide the work 
activities according to the strengths of the team. An additional month-long 
working session was then conducted at JSC to assemble the final system and 
architecture data, and to obtain team approval of this data prior to its being loaded 
into an automated Architecture Evaluation Tool (AET). One final review was held 
at the conclusion of the study to evaluate the final results, perform any required 
sensitivity analysis to gain a better understanding of what the results meant and 
obtain consensus on the single, final report. 
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2.2 ARCHITECTURE CONSIDERATIONS FOR THE HTS STUDY 

The principal considerations assessed in the study were: 

* Se paration of people and cargo . This consideration addressed whether it is better 
to physically separate people and cargo onto different launch vehicles if the 
people and cargo have a common destination. There is a perception that crew 
safety or other factors can be enhanced through this separation. In other words, 
what impact does carrying cargo have on crew safety and mission success? 

* Alternate access. This consideration addressed the impact of having an 
alternative way to deliver and return both people and cargo. The principal 
advantage of having alternate access is that there is a greater probability that a 
required mission or payload can be accomplished. The principal disadvantage is 
the cost of simultaneously operating multiple systems to do the same job. Note 
that the term assured access" is not used, since it was felt early-on by the study 
team that there was no way to assure access or to measure whether, through 
systems design, it could be achieved. 

* Commonality with or influence on the ACRV . This addressed the impact of 
either haying an ACRV and its effect on the resultant system choices that would 
be made in a transportation architecture, or identifying whether other systems 
could perform the emergency crew return function instead of a separate ACRV 
vehicle. 

* Which booster to use for human launch applications . This addressed the 
relative advantages and disadvantages of using a new versus an existing 
expendable launch vehicle for delivery of astronaut crews to low Earth orbit. 

* Role of advanced technolog y (new concepts) . This consideration addressed the 
degree to which new or advanced technology enhanced the cost, safety, etc. of a 
transportation architecture. For this study, this included only new technology 
systems, rather than technology advances at the subsystem or component level. 

* Evolution of current systems . This addressed the relative advantages and 
disadvantages of evolving the current mixed fleet of launch vehicles, compared 
with development of completely new systems. 

* Effect of return c argo requirements . This consideration quantified the impact of 
return cargo requirements on the transportation architecture. Having a return 
cargo requirement is a principal systems consideration in an architecture, as it 
requires a distinct vehicle (either expendable or reusable) to return a payload. In 
most cases, this would preclude delivery of the payload on an ELV. 

Other considerations were not addressed in this study. Although these other 

considerations may be important in and of themselves, they were judged by the 
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study team to be of lesser importance, or significantly more difficult to quantify, 
compared with the above considerations. Also, since the team believed that it 
would encounter resource limitations and difficulty in getting valid data to make 
comparisons of options which would address these considerations, it decided to 
defer an assessment of these for this study. However, the team felt that all of these 
warranted additional study. These are summarized below: 

• Influence of total SEI transportation requirements . Because transportation 
requirements for SEI would be of such a magnitude greater than Earth-to-Orbit 
requirements, and given the uncertainty of these requirements, the study team 
chose only to include the impact of crew delivery to support SEI missions on the 
ETO transportation systems. 

• Use of foreign assets . This would address the use on non-U .S. transportation 
assets for delivery or return of people or cargo. Though the study team felt this 
was an important consideration, it was not able to get the pertinent data (launch 
vehicle cost, reliability, etc.) from foreign sources within the required study time 
frame. 

• Reusable versus expendable personnel carriers . This referred specifically to the 
trade of reusable versus expendable personnel launch system (PLS) concepts. 

This was deemed to be a lower level effect than the architecture-level focus of the 
study would indicate. 

• The extent of evolution for the Space Shuttle . This addressed the idea that, 
given that evolution is the "right" answer, what level of evolution makes the 
most sense. Again, this was deemed to be a trade-study to be done at a level 
lower than the architecture-level focus of this study. 

• The degree to which technology should be "pushed" to meet an early need . This 
would explore the relationship between funding and technology readiness, i.e., if 
a certain technology was required, what level of near-term expenditures would 
be required to meet a specific program schedule. The study team felt it did not 
have sufficient information to assess this effect. 
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2.3 GROUND RULES AND ASSUMPTIONS 


In the real world, initial constraints often exist that will constrain the trade space to 
be explored in an architecture study. These extremely top-level requirements or 
groundrules, called "stone tablet" requirements, are not tradeable and must be met 
by all architectures without exception. These requirements were developed by the 
NIT consensus, and represent the best estimation of what types of groundrules 
would be considered inviolate by senior agency management. Some are based less 
on engineering trade studies than on perception or policy. One way to see these 
requirements is to think of the customer asking the following question: "I don't care 
what the architecture looks like, as long as it does the following: 

On August 16, 1991 the NIT held a brainstorming session to develop a list of stone 
tablet requirements. The inputs were subsequently grouped into different types of 
ideas: J r 

• Space Policy 

• Minimum Attribute Values 

• Operational Constraints 

• Baselined Architecture Solutions 

At this point, debate on each suggestion ensued until consensus was reached on 
whidr items should survive as stone tablets. Both the six items that survived and 
the list of rejected items are presented here, in no particular order, along with some 
elaboration on the decision to accept or reject the idea. 


2.3.1 MTS Stone Tablet Requirements 

• There can be no reliance on foreign countries to develoj? elements .— The proper 
role of existing foreign elements within an architecture is left as a trade or 
sensitivity to be explored through alternative architectures (see section 3.3). In 
deference to those who consider space hardware development as much a 
contribution to national prestige, knowledge, and future competitiveness as it is 
to science, no architectural scenario will require the development of any 
element for its successful implementation. In addition, the United States would 
have little control over the development schedule of an element for which it 
did not have any budget authority. An example would be a fully operational 
Hermes in support of the SSF permanently manned capability (PMC) which 
represents a schedule risk that is not within NASA's purview and also aids and 
abets the technological prowess of a competitor. This did not preclude use of 
existing foreign assets. 

• SSF will be assembled with the Space Shuttle up to PMC - The design of the 
SSF, which could theoretically be changed, was deemed mature enough to 
assume that the station elements are designed in a way that can only be 
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deployed or assembled by a Space Shuttle Orbiter. To avoid the concern that this 
reinforcing logic could perpetuate the Space Shuttle beyond a date where it may 
be undesirable for other reasons, it was decided that SSF activities after PMC 
could be supported by some other transportation element(s). This implies, for 
example, that growth modules could be redesigned for launch on an ELV. 

• The SSF design through PMC is fixed - The design of the SSF and its 
experiments, which could theoretically be changed to better match the 
capabilities of a given architecture, was deemed mature enough to assume that 
the station elements' mass and volume are already set. To avoid the concern 
that this reinforcing logic could perpetuate the Space Shuttle beyond a date 
where it may be undesirable for other reasons, it was decided that SSF activities 
after PMC could be supported by some other transportation element(s). This 
implies, for example, that logistics modules and/or their constituent cargo could 
be significantly redesigned, including exploring expendability options. 

• The operational requirements, procedures, and constraints of the SSF and other 
on-orbit assets are fixed - Although the approach to transporting payloads and 
people may vary, the operational rules associated with SSF and certain on-orbit 
assets must be adhered to. For example, the rendezvous and docking procedures 
for the SSF imply the element must have the capability of controlling the 
velocity vectors within the SSF-specified levels. 

• Mixed fleet manifest will be used to define the architecture through 

1996- Although it may be shown that certain elements may be phased out as 
soon as possible in the best interests of the architecture, it was assumed that the 
planning and procurement of transportation elements, and the flight and 
facilities manifesting that goes with them, has already commenced and is 
unlikely to be altered until after 1996. 

• No international treaties will be violated - It has been, and remains, the stated 
policy of the United States to cooperate with other nations so that the benefits of 
space reach all humankind. This cooperation takes the form of joint efforts, 
international contracts, and compliance with international law and treaties. In 
some cases, the generated architectures have no relationship to these treaties; 
when the specifics of operations are explored, there may be some consideration 
due to these international agreements. The following treaties and conventions 
have been ratified by the United States and are in effect. 

"Treaty Banning Nuclear Weapon Tests in the Atmosphere, in Outer Space, 
and Underwater," in force October 10, 1963. Context is self-explanatory; 
impact to this study precludes the manifesting of any DOD flights that 
would include nuclear weapons. 

"Treaty on Principles Governing the Activities of States in the Exploration 
and Use of Outer Space, Including the Moon and Other Celestial Bodies," in 
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force October 10, 1967. This so-called "Outer Space Treaty" establishes 
celestial bodies as open to all scientific investigation by any state and 
precludes any nation from claiming sovereignty, or from placing weapons 
of mass destruction on those celestial bodies, or in space. Similar to the 
Antarctica Treaties, there still is some question as to how commercialization 
and/ or resource utilization would be handled. To achieve compliance, 
within the scope of the architectures (extending to 2020), exploration should 
be limited to a national program, such as SEI, and commercial ventures 
(such as the Lunar Hilton) should be omitted. 

"Agreement on the Rescue of Astronauts, the Return of Astronauts and the 
Return of Objects Launched into Outer Space", in force December 3, 1968. 
The spirit of this treaty ensures the return of astronauts who land in foreign 
terrain or on the high seas. The implication is that emergency /abort to a 
signatory state is acceptable. Performance capabilities to reach the 
continental United States in any contingency, for example, should not be a 
requirement. 

Convention on International Liability for Damage Caused by Space 
Objects", in force October 9, 1973. This is a complex treaty that basically states 
that liability is assessed to the state from which the object was launched. For 
example, the United States is liable for damages that a spent stage might 
cause to another country after a launch of a commercial launch vehicle. 

There are several other conventions, such as the "Convention of the 
Registration of Objects Launched Into Outer Space," the International 
Telecommunications Convention (frequency allocations), and patent law, that 
are assumed to be met by all candidate elements. The legal policies for space 
environment (pollution) and jurisdiction are still evolving. For a 
transportation system, legal jurisdiction is governed by the launching countries' 
rules from the time the hatch is closed on the launch pad to the time the 
payload is delivered to orbit. 


2.3.2 Rejected Stone Tablet Requirement Ideas 

• National Security is a top priority - Historically, the DOD has provided for its 
own launch facilities and vehicles. It is conceivable, however, that future 
architectures may include a more integrated use of transportation assets. In the 
event of a crisis situation where access to space is considered a national 
imperative, civilian manifesting could be altered to accommodate the DOD. It 
was the opinion of the majority of the NIT that accounting for this possibility 
would require a level of modelling sophistication that may not be justified, 
since it would be unreasonable to expect full manifest resiliency in the event of 
a major national crisis. 
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• No use of foreign launch services is permitted - The argument against using 
foreign launch services is based on a heritage that found it advantageous to use 
U.S. assets exclusively for reasons of national security, internal economic 
growth, less scheduling risk, and national prestige. The next 30 years promise to 
be significantly different, with international ventures and contracts increasingly 
more commonplace. In the area of launch vehicles, technology transfer is 
becoming less of an issue as several nations have mature systems. In general, 
the United States is opposed to protectionist policies, and seems to be moving 
toward accepting the legality of allowing the user to select their preferred launch 
service provider. The proper role of foreign assets will be explored in the 
architecture options (see section 3.3). 

• Must be consistent with National Launch Policy (NLP).- Existing national policy 
enables governmental leadership to plan space development efforts within an 
accepted framework. A goal of the HTS study is to quantify the impact of the 
NLP on an architecture over time. For example, there are no current plans to 
build any more Space Shuttle Orbiters; what would be the impact if two more 
were added to the fleet? Rather than limit the study to options that are wholly 
consistent with national policy, other possibilities will be explored to document 
the effect of alternative "policies". 

• Must ensure dual access - Dual access is defined here as the ability to do all the 
"jobs" two separate ways. While this seductive possibility would virtually 
eliminate issues of dependability, availability, resiliency, and loss of prestige 
associated with a major failure, it could be very expensive. The requirement for 
dual access was thought by some to be a reaction to a series of failures in the 
mid-1980’s, and not a rational groundrule for all future operations. Dual access 
may be addressed in the architecture options. 

• New ways of doing business must be included in candidate architectures - Some 
of the most fertile areas for realizing future improvements in cost and 
operability involve the successful implementation of new methods of doing 
business and/or operations (see section 3.4). It is not a forgone conclusion, in 
the opinion of this group, that the customer would chose to implement these 
suggestions for all elements, especially existing ones. To that extent, it was 
decided that the best place to explore the benefits of these ideas would be in 
"Task 4: New Ways of Doing Business" (see section 2.1.4). 

• New elements must advance the state-of-the-art.- In the past, it was a foregone 
conclusion that each new element would and should advance the nation's 
scientific and engineering knowledge. Within the context of a perceived shift in 
priorities that places more budgetary emphasis on the payload and less on the 
transportation system itself, the NIT consensus was that, in many cases, the 
dictate to use new technology is often incompatible with the stated 
transportation goals of low cost and high safety and should, therefore, not be a 
requirement. This would not preclude NASA from pursuing new technology. 
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but would distinguish operational systems (used to meet the transportation 
needs defined in this study) from developmental systems. 

• The government is not the developer nor the operator of the human-tended 
transportation elements - This concept is similar to the fifth item. Again, while 
this requirement may be an excellent idea, it was thought that it could best be 
explored in section 2.1.4. 

• No new system will achieve Initial Operational Capability (IOC) before 
1999 - Given the typical development and manufacturing cycle of new 
aerospace hardware, this constraint is probably a realistic one. It was decided, 
however, that there is no reason to preclude the possibility of an aggressive, new 
program that could come into use sooner than 1999, leaving it instead as an 
architectural option that would be accounted for in terms of cost and risk. 

• The Industrial Space Facility (ISF) will be deployed by the Space Shuttle- As 
currently envisioned, the ISF is designed to be deployed by the Space Shuttle. It 
is conceivable, given that the ISF hardware has yet to be produced, that it could 
be designed to be launched on another vehicle, in which case this requirement 
was viewed as an unnecessary constraint. 

• Use only Western Test Range (WTR) and Eastern Test Range (ETR) launch 
sites - Developing new launch sites is an expensive proposition. National 
security may also require a limitation on the number and location of launch 
sites. Also, by only specifying these two launch sites, any cost estimations 
(including operations, facilities, range safety, etc.) would reflect a high degree of 
confidence in the data. If properly accounted for, a new launch site could be 
included in an architecture. This proposed requirement will not be considered 
because of the absence of any quantifiable data on the undesirability of another 
launch site. 

• No west coast launch sites - This proposed requirement is similar to the above 
item. In this case as well, the requirement will be dropped from further 
consideration, in the absence of specific measures of merit for limiting launch 
sites. 

• SSF and all "Big Science" type payloads will be prevented from falling from orbit 
at all costs - The consequences of a premature entry of complex, large, orbital 
payloads can be considerable in terms of cost (hardware, lost data, etc.), prestige, 
and impact hazards. There is a strong impetus, therefore, to make the 
establishment of procedures, hardware elements, and scheduling to prevent the 
entry of these large payloads a priority. As was the case in some other suggested 
requirements, the NIT felt that it would be difficult to credibly predict when a 
crisis would occur; since a crisis would be dealt with at that time with available 
resources, it would not, therefore, be a separate requirement. 
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• Current systems are restricted by current range-safety constraints - Over the 
years of operating launch vehicles, NASA and the DOD have developed very 
clear and effective range safety procedures that have resulted in superior safety 
records. The proposed requirement seeks to limit current systems to using those 
proven features and constraints. The NIT concluded this policy should result 
from careful range safety studies for new and existing systems, not from a 
mandated requirement. 

• Provide 2 days additional loiter time to achieve additional landing 
opportunities .— Additional on-orbit loiter time enables a low energy phasing to 
occur that would result in more landing opportunities in the event that the 
planned landing has been waved off. It was the group's feeling that whether the 
capability is 2 days, x orbits, or whatever, it should be determined as a system 
trade, not a levied requirement. 

• Minimize extravehicular activity (EVA).- This is an activity that is both a risky 
and expensive aspect of spaceflight, and should be minimized. It was felt that 
this idea would be more appropriate as a design guideline, than as a stone tablet, 
in that it would be impossible to define what an acceptable minimum level of 
EVA would be. 

• All new elements are to be largely reusable - There is a widely-held perception 
that reusability is a desirable system feature. Recurring and manufacturing costs 
can be reduced. Expendability, however, also has a place in an architecture, 
especially in cases where only a few flights are needed. It was decided to defer 
this issue to an architectural option, rather than legislating an unsubstantiated 
assertion as a requirement. 

• Human systems will accommodate "average" deconditioned humans- The 
trend in human spaceflight has been away from the test pilot astronaut and 
towards the scientist/mission specialist astronaut. These latter individuals tend 
to come from a more average physical population than the extraordinary 
physiological capabilities exhibited by a test pilot population. Future systems 
must account for the decrease in average tolerance to g-levels, dexterity, etc. 
While there was no dispute with the statement, the group felt that this policy 
requirement is superfluous in the context of discriminating between candidate 
architectures. 

• The average system downtime after a major failure will be TBD months - This 
proposed requirement falls under the category of minimum attribute values. 

To that end, the NIT decided that this idea is not a stone tablet requirement, but 
will be addressed in the attribute discussion (section 3.2). 

• Personnel vehicles must have on-board intervention capability - The ability of 
on-board personnel to have input to the events that occur during flight has been 
debated for 30 years. The proposed requirement reflects policy and philosophy. 
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rather than a technical decision. We could not hope to conclusively resolve this 
issue in this study; it was determined that this represents a level of design detail 
that won't be considered in the elements anyway, and is therefore unnecessary 
as a top-level requirement. 

• Personnel vehicles must be "piloted".- The role of a human "pilot" has also 
been a subject of recent debate both in the spacecraft and aircraft communities. 
Technically, the nation has reached a level of technological sophistication where 
flight vehicles can be safely flown with no trained pilot onboard. When it will 
be permitted for human-tended vehicles to be operated in this fashion is 
unknown. The NIT declined to include this requirement, based on previous 
studies that showed the gross technical differences in the elements of weight, 
cost, etc. for piloted and non-piloted versions were insignificant to the 
architecture as a whole. 

• All the "jobs" must be done on time- To enable an exact comparison between 
architectures, it would be necessary to demand that each candidate completes the 
delivery of all payloads and completes all other mission types before 2021. This 
requirement could, however, mandate excessive resiliency or excess capacity 
when accounting for random, worst-case scenarios. The NIT decided that as 
long as the proposed architecture has the basic capacity to complete all the jobs 
in the absence of major schedule disruptions, it will be acceptable. 

• The architecture can survive a catastrophic loss - In the event of a catastrophic 
loss involving one or more major elements, there is always the possibility that 
national leadership could decide to cancel programs or elements, rather than 
proceeding with a recovery plan. While it was acknowledged that such a 
possibility could occur, the NIT decided against declaring whether or not an 
architecture will always return to it's original element mix. 

• Probability of launching priority payloads is greater than TBD- This proposed 
requirement falls under the category of minimum attribute values. To that end, 
the NIT decided that this idea is not a stone tablet requirement, but will be 
addressed in the attribute discussion (section 3.2). 

• Reliability is greater than TBD - This proposed requirement falls under the 
category of minimum attribute values. To that end, the NTT decided that this 
idea is not a stone tablet requirement, but will be addressed in the attribute 
discussion (section 3.2). 

• Dependability of 95 percent within 2 weeks of scheduled launch- This proposed 
requirement falls under the category of minimum attribute values. To that end, 
the NIT decided that this idea is not a stone tablet requirement, but will be 
addressed in the attribute discussion (section 3.2). 
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• All systems must be at least as safe as TBD.- This proposed requirement falls 
under the category of minimum attribute values. To that end, the NIT decided 
that this idea is not a stone tablet requirement, but will be addressed in the 
attribute discussion (section 3.2). 

• Total Life Cycle Cost (LCC) is less than TBD.- This proposed requirement falls 
under the category of minimum attribute values. To that end, the NIT decided 
that this idea is not a stone tablet requirement, but will be addressed in the 
attribute discussion (section 3.2). 

• The transportation system should be environmentally "friendly".- Recently, a 
large amount of attention has been given to our impact on the environment, 
including space launch activities. As stated, the requirement lacks an acceptable 
threshold. It was decided to treat environmental impact as an attribute, which 
could reflect the continuum of relative impact a given architecture might 
exhibit. 

• Humans must remain in the launch decision process - In the advent of 
automated procedures and vehicle health monitoring technologies, it is possible 
to fully automate the launch decision process to account for all measurable data. 
There will continue to be value in the role of a human to make a judgement, 
based on the data presented. Even accounting for human error, it was 
considered unacceptable that a computer could commit to the launch of a 
personnel vehicle. While there was no dispute with the statement, the group 
felt that this policy requirement is superfluous in the context of discriminating 
between candidate architectures. 

• Abort must be provided for in all flight phases - There has been much scrutiny 
(especially post-Challenger) of the ability of a vehicle to safely abort at all times 
during its flight. The time periods where no escape exists in the event of a 
catastrophic failure are typically short, but the loss of personnel is unacceptable, 
regardless of when it occurs. The inclusion of abort capability can impose 
significant performance penalties. The consensus of the group was that, while a 
worthy goal, the proposed requirement was better served by trade studies that 
adequately account for costs of providing and costs of not providing (cost of 
failure) an all-aspect abort system. 
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SECTION 3 
STUDY TASKS 


3.1 TASK 1 - HTS NEEDS ANALYSIS 


3.1.1 Introduction 

To facilitate identification of the requirements and potential options for the next 
HTS, a needs analysis was performed from which space transportation architectures 
were created and analyzed. This analysis identified the number, mass, type, and 
destination of human and untended payloads to space. The payloads were then 
broken into several categories based on a common mission or theme. 

The needs model is based on the NASA Mixed Fleet Manifest and the CNDB FY90 
version with Space Station restructure modifications and an additional 
representative DOD mission model. Upper-stage weights for those payloads going 
beyond LEO and required support equipment were not included. This was, 
however, accounted for when flight manifests were generated for the transportation 
architectures. Payloads were categorized as "Untended" or "Human Receipt at 
Destination." The only missions requiring a human categorization were for SSF 
and SEI crew delivery. All other missions were classified as "Human Receipt." All 
mission payload crew sizes were four persons, although extra persons might be 
required to support and operate the human vehicle. 

Needs-Based versus Capability-Based Approaches 

To compare architectures on an even basis each architecture must meet the same set 
of requirements. This needs-based approach was accomplished by establishing a 
common model of the space transportation needs. The architectures could then be 
compared because each was performing the same set of missions. 

The alternative is to compare architectures by the capabilities of the space 
transportation elements that comprise them. The underlying assumption is that the 
user community will make use of any vehicle that is available (i.e., let the 
transportation system drive the payload design and operational requirements as a 
higher priority to the mission). Although there may be some realism to this 
philosophy with respect to how new systems are sold to Congress, there is a danger 
in developing a launch system that does not meet user requirements or that 
requires extensive modifications to payloads or their carrying vehicles. In addition, 
it becomes difficult to compare these architectures or systems to each other. For 
instance, larger payload capability does not necessarily mean cost efficiency because 
some flights may only be partially filled. Also, minimum cost architectures may not 
meet the flight rate or performance requirements of the users. 
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Previous Studies 


One of the more notable studies performed on the future of space transportation 
was the STAS, which was performed in the mid-1980's. At this time, the budget for 
space activities was expected to grow significantly over the coming years. The 
mission models developed for that study, which were later to become the CNDB 
were extremely optimistic, greatly exceeding anything that could reasonably be 
expected today. These missions included the SDI in its largest scale, aggressive 
Lunar and Mars Initiatives, human missions to Geosynchronous Earth Orbit (GEO), 
and extensive ETO and in-LEO infrastructures. The smallest STAS mission model 
(Constrained Model) is equivalent to the largest mission model currently developed 
for this study. 

Since the STAS, several other architecture-level analyses have been performed. 
Many of these studies were performed within the scope of a specific vehicle 
development program (e.g., NASP-derived vehicle (NDV) Task 11, ALS, etc.). The 
purpose of these studies usually focused on assessing the role of a specific 
transportation system within the national space architecture. The mission models 
developed were often modified to enhance the characteristics of the system being 
studied. 

The Next Manned Transportation System (NMTS) study was performed in 1989 to 
assess future human transportation requirements. The needs model for this study 
was primarily based on the CNDB with a series of additional groundrules. 

More recently, the STIS at MSFC has been analyzing architectural impacts of various 
systems, missions, and operations. The STIS has taken a similar approach to the 
HTS Study in the needs analysis area. The difference between STIS and HTS lies less 
in the needs model area and more in the choice of architectures selected for study 
and the evaluation process used. 


3.1.2 The CNDB 
Background /Description 

The CNDB was established in 1985 by NASA Headquarters to project future, civil- 
space payload requirements. These requirements are developed in the various 
NASA Headquarters Codes and are then integrated and released by the Office of 
Spaceflight Development. The payload types range from Space Station build-up and 
logistics support, to Spacelab missions, to Tracking and Data Relay Satellite (TDRS) 
deployment, to small experiments such as growth of frog eggs and fruit flies. Each 
payload in the database has a description of the mass and volume requirements, 
return payload requirements, whether the payload requires human interaction, the 
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date of first launch, the number of required launches, and programmatic points of 
contact. 

Analysis of the CNDB 

For the HTS study, the standard RBASE version of the CNDB was converted for use 
on the Macintosh using the Acius 4th Dimension database management program. 
The payloads of the CNDB were then divided into seven distinct mission types: 

SSF, Satellite Servicing, Support Assets, Industrial Space Facility, Sortie Science, 
Base, and SEI. In addition, a DOD mission model was incorporated into the study. 
These mission types are described in detail later. 

One of the most interesting results found in reviewing the CNDB is that the 
proposed mass to be sent to orbit during the next 15 years is seven times greater than 
that sent to orbit during the past 15 years (see Figure 3.1.2-1). This reflects the 
expectation of increased space flight activity (e.g., SSF). Nearly two-thirds of all non- 
SEI, non-DOD mass that will be delivered until 2020, is to build and support SSF. 
Also, 43 percent (by mass) of payloads require crews to be aboard the launch vehicle. 
Finally, one quarter of all mass sent to space is to be returned; the majority of that is 
the return of Space Station logistics modules. Two-thirds of the payloads (by 
number) weigh less than 1000 pounds and 80 percent weigh less than 10 000 pounds 
(see Figure 3.1. 2-2). For the return payloads, 83 percent of these payloads weigh less 
than 1000 pounds, and 94 percent weigh less than 10 000 pounds (see Figure 3.1. 2-3). 

Shortcomings of the CNDB 

There were several difficulties in using the CNDB for the HTS study. Some of these 
were compensated for by simplifying assumptions in the HTS Needs Model. Others 
could not be handled, and their inclusion in future versions of the CNDB would 
enhance results obtained in future space transportation architecture analyses. 

First, many payload requirements are based on the current transportation 
architecture. Examples include requiring payloads to be returned based on Space 
Shuttle flight-return capability rather than a true need for the returned payload, and 
requiring SSF payloads to be serviced at each crew rotation opportunity. It is 
recommended that hard payload requirements should drive the systems which 
comprise the space transportation architecture, not the reverse. 

Second, a large number of payloads in the CNDB claim to require human 
interaction with the payload (e.g.. Advanced X-Ray Astronomy Facility (AXAF)). 
Many of these payloads could be placed on cargo vehicles or could simply require 
personnel at the destination, such as for SSF payloads. Similarly, many payloads 
have a return requirement, the necessity of which should also be carefully 
considered. 
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CNDB Projection 
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Figure 3.1. 2-1.- Total payload mass delivery and return - ETO (dvil and available) 
DOD, no SEI or SSF expansion). 
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Third, one of the problems in analyzing payloads from the CNDB is that there is no 
sense of the urgency or criticality for launching a particular payload at a particular 
point in time. An attempt to avoid this has been made by defining mission types 
which have roughly the same level of need. If a mission type is included within a 
transportation architecture scenario, all missions within that type will be flown. 
Some payloads may require a very specific launch window (e.g., a Pluto fly-by or 
Mars Observer) which might make that payload much more critical in terms of on- 
time launching than perhaps an LEO Great Observatory. To this end, NASA should 
develop a way to assess or rank a payload based on its criticality. These criticality 
levels should appear with the payload descriptions in the CNDB. This could be 
done in four levels: 

• Loss of life or major infrastructure component (e.g., SSF reboost) 

• Loss of mission opportunity window (e.g.. Mars flight) 

• Loss of minor infrastructure component or mission (e.g., Hubble Space Telescope 
(HST), Long-Duration Exposure Facility retrieval) 

• Little or no impact of delays to mission success (e.g., Spacelab Simulator-1, 
Gamma Ray Observatory (GRO) deployment). 

Finally, there are at least two ways of skeptically viewing the payload model 
credibility of the CNDB. The first view claims there are many more payloads in the 
data base than will be flown. While it is true there are many placeholders in the 
data base, and that future payload projections are much higher than the nation has 
launched into space in recent history, it is also true that the space program is 
proposing much more ambitious endeavors in space by building a permanent space 
station, attempting to return to the Moon, and going to Mars. The second view 
states there are many more payloads "out there" than have been incorporated into 
the data base and/or if the transportation infrastructure had enhanced capabilities at 
reduced cost, there would be many more payload requirements. 

As a result, some believe that because the CNDB does have shortcomings, it should 
not be used or that a mission model approach is not appropriate. Shortcomings 
should not invalidate the use of mission models, rather their presence demands 
greater rigor in developing hard payload requirements. 
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3.1.3 HTS Needs Model 


3.1.3.1 Modifications to the Needs Model 

A principal implication of using the CNDB in an unmodified form would be to 
require an architecture that includes a system with Space Shuttle-like characteristics. 
Because of the "Human" requirement specified by many of the payloads in the 
CNDB, the systems that carry crew and cargo on the same vehicle are the only ones 
that would correctly capture these missions (i.e.. Space Shuttle). In addition, because 
of the identified delivery and return payload sizes, at the least a Space Shuttle-like 
capability would be required to perform certain delivery and return missions. 

Payload Requirements 

Due to the difficulty in understanding what true human requirements were, all 
"human" and "Space Shuttle" requirements were changed to "Human Receipt at 
Destination". This means that instead of requiring that personnel fly with the 
payload or that a payload must fly on the Space Shuttle, a payload was only required 
to have human interaction with the payload while on orbit. This allowed 
transportation architectures which would separate people and cargo. While it was 
highly likely that a Spacelab mission would be flown aboard the Space Shuttle, it 
was not required. 

Smoothing 

Because the near-term (before 2000) space transportation needs are easier to predict 
than the longer term (after 2000), the CNDB exhibits a "bow wave effect", that is, 
payload requirements in the next few years greatly exceed the out-year requirements. 
Many believe that this requirements bow wave will continue to exist at any point in 
time because of the emphasis on near term mission planning. Designing an 
architecture to meet this type of time-phased effect would be shortsighted. To 
effectively assess the architectural impacts through 2020 and the life cycle cost of 
various systems, the HTS study needed a mission model that accurately reflected the 
most probable space missions through this time period. Therefore, the study team 
chose to perform a smoothing on the mission types that would otherwise dwindle 
to near zero in the out-years. Figure 3. 1.3.1 illustrates the idea of smoothing on the 
level of mission type flight activity. Five of the mission types were subsequently 
smoothed in this fashion. 


3.1-7 


Rev. E 




Figure 3.1. 3.1.- Mission type payload "smoothing". 


3.1. 3.2 Mission Types 

The payloads in the HTS Needs Model were divided into eight mission types or 
groups of activity that had similar characteristics. These mission types are described 
below. Appendix A (see Volume II) provides a summary of the mission model 
payload requirements by mission type and year. Commercial payload requirements 
were not included, since these would have little or no cost impacts to any proposed 
transportation architecture. 

# 

POD 

This category includes piloted and unpiloted DOD missions. Though not a part of 
the CNDB, the NASA-Industry team believed it was important to include DOD 
requirements, since their Expendable Launch Vehicle (ELV) and human flight 
requirements, as well as ground-processing facility requirements, would have a 
synergistic effect on the costs of a particular transportation architecture to NASA, 
and because they resulted in government expenditures whereas commercial 
missions did not. The unpiloted data for this category was obtained from the MSFC 
Space Transportation Infrastructure Study and is expressed in terms of vehicle class 
launch rates, rather than specific missions or payloads. This is a capability-based 
(number of expected flights) model due to the classified nature of the needs. 

To select the DOD piloted mission requirement, 10 of the 45 Space Shuttle flights 
since 1981, have been dedicated to DOD, an average of about one per year. (In the 
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NASA Mixed Fleet Manifest, there is an additional flight in 1992, with no additional 
flights forecasted or manifested after this.) Based on this information, DOD will 
continue with a human mission requirement of one per year. It is also assumed 
that the DOD piloted missions will require some cargo, but not necessarily on the 
same flight or vehicle. This is a reduction from the requirement used in the NMTS 
study in 1989 which identified a piloted mission requirement for future DOD 
missions of three flights per year. 

Base 


This category is comprised of basic science and technology development payloads 
which have low return requirements. Example payloads are GRO, Earth 
Observation System (EOS), Cassini, and the Combined Release and Radiation Effects 
Satellite (CRRES). It also includes the middeck-size payloads flown aboard the Space 
Shuttle. All payloads in this category have a return requirement of less than 1000 
pounds. This category should not be confused with the CNDB Base Model. 

The Base mission type is comprised of the EOS , Planetary, LEO-Large (11 000 lbs.), 
LEO-Small, and LEO-Human Receipt payloads. Each of these smoothed payloads are 
flown once a year for an annual mass to orbit of 65 000 pounds. The LEO-Human 
Receipt has the only return requirement. 

Su pports Assets 

This category constitutes high-priority, space-based infrastructure satellites for 
communications, tracking, and data relay. The nine payloads in this mission type 
reflect operational versus scientific or developmental systems, and would have a 
very high launch priority compared to other science or exploration missions. 
Example payloads are TDRS, GN&C Orbital Environment Simulation, and the 
International Maritime Satellite (INMARSAT). There are no human requirements 
in this category, although a few of these payloads will be carried aboard the Space 
Shuttle. 

The Support Asset mission type is smoothed by destination. It includes GEO-large, 
Sun-synchronous, GEO-small, and mid-inclination payloads. The average mass 
delivered per year is 5000 pounds. 

Industrial Space Facility 

This category includes those payloads which comprise the Industrial Space Facility 
(ISF). For the HTS study, a reduced-scale ISF payload model was used based partially 
on recommendations from the MSFC STIS. All payloads in this mission type have 
a common destination. 
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Sortie Science 


This category includes larger, "Spacelab-type" missions which have return 
requirements greater than 1000 pounds. Example payloads are Space Life Sciences, 
the Astronomy Ultraviolet Telescope (ASTRO), and the International Microgravity 
Laboratory. Payloads requirements in this mission type strongly reflect Space 
Shuttle-based transportation architecture. 

The Sortie Science mission type is categorized by four different types of payload 
mixes being flown once a year from 1998 to 2020 (total of 69 000 lbs. per year). These 
include Office of Space Science and Applications Cargo, Material Sciences, Earth/ 
Astronomy Observation, and other pressurized cargo. It is assumed all delivered 
mass is returned. 

Satellite Servicing 

This category includes satellite servicing missions for repair, reboost, maintenance, 
retrieval, and upgrade of LEO satellite systems. It does not include servicing 
missions for SSF or SEI. 

The Satellite Servicing mission type was smoothed from 2011 to 2020 to reflect 
alternating requirements for large and small servicing flights for a total of 19 000 
pounds per year. The Large Deployable Reflector and HTS servicing missions are 
included prior to 2010 (8600 lbs.). 

SSF 


This category includes those payloads which comprise SSF. This includes assembly, 
utilization, logistics, crew rotation, and expansion flights modified to the latest SSF 
design configuration restructure. However, the actual user payloads were the same 
as those of the FY90 version of the CNDB. Even though the restructure activity will 
greatly impact non-core, SSF-related payloads, developing a new payload model 
with a reasonable degree of confidence would have been very difficult for this study. 
Since these payloads represented only a fraction of the core station weight, it was 
assumed that the overall mass of these payloads would not change significantly 
from the FY90 CNDB. This assumption must be revisited, since it is likely that after 
the restructure, payload requirements far exceed available capability. Therefore, data 
for all non-core, SSF-related payloads came from the FY90 CNDB. However, all first 
flights for the payloads were shifted later by 2 years to reflect the changes in the 
station design and schedule due to restructure. 

The SSF mission type was further broken down into a PMC model which included 
assembly, operations, and support of the PMC configuration, and an expansion 
model which included any non-SEI expansion to the PMC configuration 
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(e.g v Eight-Man Crew Capability (EMCC)). All payloads in the SSF mission type 
have a common destination. 

In the SSF mission type, the SSF logistics and utilization flights were smoothed to 
reflect a continuation of the PMC support requirements through 2020. Similarly 
"If" scenario D was smoothed to continue the EMCC support requirements. 

Since no official SSF crew rotation policy exists, the following assumptions were 
made for the study so that the number of flights required to support SSF crew 
rotation could be established. 

• The entire four-person crew during the PMC phase will be rotated every 90 days. 
(After some certification, the crew would probably be rotated every other flight 
for longer duration tours of duty.) 

• During an eight-crew phase, only four crew members can be rotated during a 
human flight. This implies a 180-day tour of duty. 

All Space Shuttle flights to the SSF have a crew of seven. Other personnel 
vehicles have crew sizes ranging from four to seven. 

SEI 

The model for SEI in the HTS study is based on a high-and-low traffic requirement 
for crew-to-LEO to support human missions to the Moon and Mars. This 
requirement was established based on recommendations of possible SEI activity 
levels from the NASA 90-day Study and the Synthesis Group report. The 
manifesting considered only delivery missions, since it was assumed crew return 
would be handled by direct return or rendezvous with SSF. Lunar and Mars cargo 
requirements were not considered since these requirements are still emerging and 
the proposed scope of activities would mean large differences in the payload 
requirements. Also, since it is likely that a heavy-lift launch vehicle would be 
required and that this vehicle would be oversized for crew transportation 
requirements, there would be little synergism between this vehicle and one required 
for transporting crew to LEO. This assumption will be revisited in future studies. 


3-1-4 HTS Data Base Summary 

Once the above modifications had been incorporated, the resultant needs set was 
renamed the HTS Data Base. Table 3.1.4 shows the total mass delivery and return 
requirements by mission type for the study data base over the study time frame. 
Note again that the overall delivery mass in the HTS data base excludes the SEI 
cargo requirements. Individual mission type requirements are somewhat higher 
than the CNDB requirements since (smoothed) payloads have been added in the 
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out-years to account for ongoing support requirements. Appendix A (see 
Volume II) provides a summary of the mission model by mission type and year. 


TABLE 3.1.4.- SUMMARY OF HTS MISSION MODEL PAYLOADS 
BY MISSION TYPE (1991-2020) 


Mission Type 

Total Mass Up 
(klbs) 

Total Mass Down 
(klbs) 

SSF (incl science) 

7405 

4487 

Sortie Science 

2531 

2565 

Support Assets 

212 

0 

ISF 

107 

13 

Sat Serv (no SEI or SSF) 

259 

214 

Base 

1463 

182 

SEI 

- 

- 

DOD 

- 

- 




TOTAL 

11977 

7461 I 


Finally the eight mission types were combined into five levels of possible future 
space activity. These levels are called "If" scenarios, i.e., "If the range of expected 
space activity includes..." These levels are additive and represent increasing levels 
of requirements, not only in terms of payload to and from space but also additional 
vehicle capabilities (RMS systems, on-orbit stay times, etc.) Dividing proposed space 
activity into different levels gives the customer insight into the effect of various 
payload requirements on the space transportation architecture. 

The five activity scenarios are shown in Figure 3. 1.4-1. "If" scenario A represents 
what would likely be the minimum level of space activity the nation would pursue. 
"If’ scenario B represents the current level of space activity. "If" scenarios C and D 
represent the addition of SSF and its proposed expansion. Finally, If scenario E 
represents the inclusion of the SEI crew missions. These "If" scenarios are then 
used to manifest the system concepts of interest across the range of transportation 
architectures to be studied. Figures 3.1 .4-2 and 3.1. 4-3 show the Human Receipt mass 
required to be delivered and returned per year for the various activity levels. 
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Mass Up per Year (lbs) 


Scenario A 
Support assets DOD^ 
Base ISF 


Scenario B 
Support assets DOD Base 
ISF Satellite Servicing 
Sortie Science 


Scenario C 

Support assets DOD Base ISF 
Satellite Servicing Sortie Science SSF (PMC) 


Scenario D 
Support assets DOD Base 
Satellite Servicing Sortie Science SSF (PMC) 


ISF 

SSF (Expansion) 


Scenario E 

Support assets DOD Base ISF 
Satellite Servicing Sortie Science SSF (PMC) SSF ( Expansion ) SET (Low & High) 


Figure 3.1. 4-1.- HTS "If" scenarios, "If the range of expected 
space activity includes...". 



Figure 3.1. 4-2 - Human receipt mass up per year for each "If" scenario. 
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Mass Down per Year (lbs) 



Figure 3. 1.4-3 - Human receipt mass down per year for each "If" scenario. 
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3.2 TASK 2 - IDENTIFICATION OF SIGNIFICANT ATTRIBUTES 


The UTS Study was initiated to gather data to determine the right transportation 
system architecture(s) needed for human access to space. To determine this set, a 
method for comparing the candidate systems had to be defined. Attributes are the 
means that the HTS study team used to make those comparisons. Attributes allow 
comparison of elements that meet the requirements and the needs (mission model). 
This section discusses the need for and definition of attributes, as well as the process 
used to determine them. 


3.2.1 Approach 

One of the first tasks that the HTS team set out to address was the definition of the 
attributes that would be used in the HTS study. The attributes chosen and the 
measurement techniques used determined what information would be needed 
about each of the concepts being investigated. The attributes ultimately chosen by 
the HTS team were derived from a list of nearly 130 attributes that were initially 
proposed. Certain techniques used in Quality Functional Deployments (QFD) were 
used to arrive at consensus on the final list. 

The attributes defined in detail for this study are: Funding Profile, Probability of 
Mission Success (PMS), Human Safety, Architecture Cost Risk (ACR), Launch 
Schedule Confidence (LSC), Environment, Dependability, Availability, Resiliency, 
Alternate Access, and Mission Growth Potential. Each of these is listed below along 
with its definition. 

Midway through the study it became apparent that some of the lower-weighted 
attributes were taking a large percentage of the available study time to calculate. It 
was also felt by the HTS team that the measurements needed for two of the 
attributes in particular (Dependability and Availability) were difficult to generate 
and more difficult to justify. Therefore, the calculation of these five attributes was 
deferred to a follow-on phase. These attributes include: Dependability, Availability, 
Resiliency, Alternate Access, and Mission Growth Potential. While the 
Environment attribute was judged to be less important than the other five, its 
calculations were essentially completed, and so the HTS team decided to continue to 
use it and observe its effect on the architecture decisions. Its relative importance, 
however, was not increased above those that had been deleted. Given that the three 
operations-related attributes; Dependability, Availability, and Resiliency, were 
eliminated in this phase, the group felt that some indication of an architecture's 
ability to meet launch schedules should be included. Therefore, the LSC attribute 
was defined. It is simpler to calculate than the others, but unfortunately is also a less 
accurate indicator of an architecture's ability to meet schedules. 
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3.2.1.1 Definition of an Attribute 


Attributes are the means by which an architecture's "goodness" is determined in 
order that it may be compared with other architecture options. Attributes must 
have certain characteristics in order to be useful in performing this comparison 
function. Many of these characteristics have been effectively described by Dr. 
Deming in the context of how important measurement is in improving the quality 
of any system. These important characteristics of attributes are listed below. 

a. To be useful in comparison, the attribute must be defined and be measurable. 

"An operational definition puts communicable meaning into 
a concept. Adjectives like good, reliable, uniform, round, tired, 
safe, unsafe, unemployed have no communicable meaning until 
they are expressed in operational terms of sampling, test, and 
criterion." 1 

b. The measurements must be repeatable, which in turn means that the 
calculations are well understood and the assumptions are clear and used 
consistently across each architecture. 

"An operational definition... must be communicable, with 
the same meaning to vendor as to purchaser, same meaning 
yesterday and today... Without an operational definition, 
investigations of a problem will be costly and ineffective, almost 
certain to lead to endless bickering and controversy." 1 

c. A level of detail and accuracy of the measurements needs to be agreed upon. 
There are no absolute right or wrong values for any measurement. 

"Any physical measurement is the result of applying a given 
procedure. Likewise with the count of people in an area. It is to 
be expected that two procedures for measurement or for 
counting will give different results. Neither of the two figures is 
right and the other wrong. The experts in the subject matter 
may have a preference, however." 1 

d. Also, no new system will have the detail or empirical data that the Space 
Shuttle system has until the system is built and flown for over 50 flights. 
However, the agency cannot afford to build every option and fly it before it 
makes a decision. Therefore a preferred procedure specifying the level of detail 
and accuracy adequate to make decisions at the chosen level must be defined. 
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"A preferred procedure is distinguished by the fact that it 
supposedly gives or would give results nearest to what are 
needed for a particular end... ' 1 

e. The weighting of each attribute relative to the other attributes must be 
determined. It is the combination of all the weighted attribute scores that 
determines the best answer. Weighting is important to understand, because 
every customer does it in the process of making decisions, whether he does it 
consciously or unconsciously. The magnifying of one attribute, by expending 
resources and placing emphasis on it solely, misses the fact that few decisions 
are made based on a single criterion. 

3.2.1. 2 QFD Process for Determining Study Attributes 

To determine the attributes, it was important to do two things. The first step 
involved getting a large cross-section of the aerospace community's views, 
opinions, and ideas about what important characteristics (attributes) the next HTS 
should have. The second step required getting a consensus from this group as to 
what the most important of these characteristics (attributes) would be. These would 
be the attributes used in the HTS study. The first objective was met by creating the 
HTS team, as described in section 2.1.1. Members of the team included 
representatives of the major aerospace corporations, as well as the major NASA 
centers. A forum was set up to accomplish the second objective. The forum was 
comprised of representatives from each of the HTS team centers or contractors. 

Rules for discussion (some derived from QFD techniques) were established in order 
to facilitate the meeting of the objective. The HTS forum began by using three 8- 
hour sessions. At the end of these three sessions, the name and definition of the 
major attributes had been agreed to. During the next three months, detailed 
measurement techniques for the attributes were developed and later agreed to by the 
forum in follow-up meetings. The major rules of the forum were as follows. 

a. Keep the forum to a controllable size. This allows adequate time for each 
member to participate. The HTS forum was limited to 12 people. If other 
persons in a representatives group wanted to add something, they would funnel 
it through the forum representative of that group. 

b. Keep the membership of the forum consistent and make attendance mandatory. 
If the people on the forum are constantly changing, much time is lost educating 
the new members on the previous work of the forum. 

c. Use a facilitator. The facilitator should be knowledgeable on the subject being 
discussed and be able to focus the group and keep it on track without controlling 
the discussion. 

d. Allow each member to discuss their position without being interrupted. 
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e. The time allotted for the forum must be adequate for the group to reach 
consensus. 

The forum proceeded using the following process. First, an agreement on who the 
customer for the next transportation system would be. The forum began by defining 
the responsibilities of the person who was likely to be the customer. Those 
responsibilities included (a) ensuring that the transportation needs are 
accomplished, (b) resolving what the total (human and untended) transportation 
architecture should be, (c) determining how that architecture is implemented and 
operated, and (d) deciding how the total architecture is funded. After much 
discussion, the HTS forum agreed that the NASA administrator best fit this 
description. 

The forum then proceeded to brainstorm on what attributes the customer would 
consider important. Over 100 separate attributes were suggested. Then similar 
attributes were grouped and definitions were refined. The first gathering of 
attributes is shown in Table 3.2.1. 1-1 (no prioritization is implied). 


TABLE 3.2.1. 1-1.- FIRST GROUP OF ATTRIBUTES 


Schedule/Risk Group 
Cost Risk 
Technical Risk 
Schedule Risk 
Launch-On-Demand 
Schedule Assurance 

Cost Group 
Production Cost 
Fixed Cost 
Marginal Cost 
Non-recurring Cost 
Procurement Cost 
Discounted LCC 
$/Fiight 

Operations Costs 
Unreliability Costs 
Peak Year Funding 
Affordable 
Cost Less 
$/Ib 

Lowest LCC 
Opportunity loss to 
grounded fleet 


Assured Access Group 
’Assured’ Access 
Dual Access 
Alternate Access 

Reliability Group 
Dependability 
Supportability Routine 
Robustness 
Reliability 

Availability Group 

Availability 

Maintainability 

Operability 

Resiliency 

’Other’ Group 

Facilities 

Complexity 

MTBF 

Capability 

STS Complimentary Ops 
Support of STS Phaseout 
IOC date 
Flight Rate 
Responsiveness 


Enabling Group 
Longer Duration 
Excess Payload Capability 
Servicing Missions 
High Inclination Orbits 
Growth Potential 
Enhanced Capabilities 
Supply-Side Capability 

Safety Group 
Robust Abort Capability 
Number of Cat. Failure 
Modes 

Abort in All Phases 
Abort Capability 
Minimize Crew Losses 
No gaps in crew escape 
Landing Opportunities 
Complexity 

Crew can survive cat. loss 
Crew Impairment 

Public Perception Group 
National Prestige 
Confidence 
Politically Acceptable 
Spinoffs 

Broad Constituency 
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TABLE 3.2. 1.1-1.- FIRST GROUP OF ATTRIBUTES (CONCLUDED) 


Flexibility Group 
Operational Versatility 
Landing Opportunities 
Level of Autonomy 
International Capability 
ACRV Functionality BIT 
All Inclination Launch 


Other' Group - Concluded 
New Technology 
New Elements push SOTA 
Uninterrupted Fit. Ops 
Number of Failure Modes 
Must do all jobs on time 
Fewer Problems 
Ease of System Upgrades 
(Modularity) 


Public Perception Group - Concl. 

Environmentally Friendly 

Excitement 

Aesthetics 

Early Results 


The next attempt at consensus resulted in a reduced list of attributes (again, in no 
particular order). These discussions involved critically evaluating each attribute, 
removing requirements, and removing unmeasurable items. The reduced attribute 
set is shown in Table 3.2.1. 1-2. 


TABLE 3.2.1. 1-2.- REDUCED LIST OF ATTRIBUTES 


Flexibility 
Safety 
DDT&E Cost 
LCC 

Availability 
Cost of Failure 
Supportability 
Schedule Risk 
Job Complete 
Procurement Costs 
Operational Versatility 


Maintainability 
Fixed Cost 
Robustness 
Reliability 
Funding Profile 
Resiliency 
Margins 
Technical Risk 
Operations Costs 
Other (perception) 
PMS 


Producibility 
Dependability 
Enabling 
Marginal Cost 
Operability 
Assured Access 
Routine 
Cost Risk 
Alternate Access 


Further debate and voting ensued to reduce the list to its final form. The votes 
taken were not to enforce majority rule, but to limit the list to the attributes the 
group thought most important. If, for instance, a member of the forum was the 
only member to think a particular attribute was highly weighted, it was not auto- 
matically eliminated. A discussion ensued where the defender of the attribute 
would propose why he felt the attribute was important. This allowed the group to 
see each others point of view. Many of the disagreements concerning the final list 
were handled this way. Table 3.2. 1.1-3 shows the final list at this point in the 
process. 
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TABLE 3.2.1. 1-3 - FINAL LIST OF ATTRIBUTES 


Safety 

Availability 

Mission Growth Potential 

Program Risk 

Funding Profile 

Resiliency 

PMS 

Dependability 

Environment 

Alternate Access 


The rationale for excluding certain previously suggested attributes is also important 

as it may provide insight into the NIT group psychology. The following terms 

attempt to capture the primary reasoning behind the exclusion of certain attributes. 

• Producibility - Produdbility will show its effect under cost. However, its effect is 
small compared to the other cost drivers. 

• Supportability - The effect of supportability should show its effect as part of 
availability. A concept with poor supportability will lengthen its own average 
turnaround time. 

• Assured Access - The factors that contribute to assured access include reliability, 
dependability, and PMS; which are attributes in themselves. Additionally, 
alternate access will be one of the architectural considerations, and comparison of 
competing architectures should reveal the benefits and costs associated with 
assured access. The group felt that alternate access was a better attribute because 
of the implied certainty of assured access. 

• Job Complete - It was resolved that the HTS study would manifest all jobs to be 
competed by the year 2021 and therefore, no system or architecture would have 
done less than the complete list of jobs. 

• Cost of Failure - Cost of failure is accounted for in cost attribute. 

• Marginal Cost - Marginal cost was included in the calculation of architecture cost. 

• Routineness - Routineness was thought to be similar to dependability. 

• Margins - Margins would be reflected in values for safety, risk, reliability, etc. 

• Maintainability - Maintainability was considered part of the availability and/or 
dependability attributes. 

• Flexibility - Flexibility was be rolled up into the dependability and availability 
attributes. 
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• Cosf Risk, Technical Risk, and Schedule Risk - These were assembled into a 
larger risk attribute. 

• Operability - The group was at first divided on whether this would be included in 
cost or dependability. Since those are covered as attributes, operability did not 
need to stand as a separate attribute. 

• Procurement Cost - The study will provide all costs at a top level breakdown. 

The customer can break out procurement cost separately, but it was felt there was 
no need to distinguish it as a distinct attribute. 

• Technology Advancement - Technology should be viewed as a means to an end 
for the transportation job. Only if the technology helped to reduce cost or 
maximize the value of any important attribute, would it be used. 

• Reliability - Reliability will be incorporated as an element of PMS or some 
similar attribute. 

• Operations Costs, DDT&E Costs, LCC, Fixed Costs, etc. - All costs will be rolled up 
into a funding profile attribute. All these line items should be apparent in the 
HTS data, but it was determined that one group could not meaningfully (as the 
customer might) weight these various elements of cost. 


3.2.1. 3 Determination of Attribute Weights and Utility Curves 

The HTS team decided to develop an analytical/mathematical process, whereby the 
attribute scores could be combined and the ranking of the architectures could be 
determined. The HTS team understands, however, that the results of this process 
can not, in and of itself, be accepted as the final answer. Careful attention must be 
paid to the impact of the analytical/mathematical process itself on the answer. The 
process used by the HTS team did, however, provide valuable insight into the major 
trends and drivers that affect an architectures ranking. 

Two analytical /mathematical processes were proposed in the HTS study. The first 
method, called the direct method, begins by converting the attribute value, dollars 
for cost, crew loss events for safety, etc., into a non-dimensional value. Utility 
curves can be used for this purpose. This technique requires that the HTS team 
determine the shape and boundaries of the utility curve. The group determined 
that since there was no minimum or maximum acceptable value for any attribute 
(otherwise it would be a requirement), the utility curves should range linearly from 
the best attribute score in each "If" (activity scenario) being normalized to 1.0, to the 
worst attribute score being normalized to 0.0 (see Figure 3.2.1. 3-1). A linear utility 
curve relationship was chosen as a simplifying assumption, since a more complex 
mathematical relationship could not be justified. In Figure 3.2.1. 3-1, the cost values 
of roughly $50 billion and $150 billion are examples of the best and worst funding 
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profile attribute values for all the architectures in a particular "If" scenario. The 
weighting of one attribute versus another must also be determined. The HTS 
members assigned each attribute a weight. The weights of the individual attributes 
must add up to 100. The results of this scoring were shown to and commented on 
by high-level representatives of the customer (i.e., JSC Center Director). This was 
essential, since if the weightings are not consistent with the customers views, the 
conclusions could be inaccurate. Weights for the initial set of attributes as well as 
the weights for the final set of attributes are shown in Table 3.2.1. 3-1. 



Lowest cost of all Highest cost of all 

Architectures in Architectures in 

this "If". this "IP. 


Funding Profile 

Figure 3.2. 1.3-1.- Example attribute utility curve. 


TABLE 3.2. 1.3-1.- BASELINE ATTRIBUTE WEIGHTINGS 


Attribute 

Complete Set Weight 

Abbreviated Set Weight 

Funding Profile 

22 

27 

Human Safety 

18 

29 

PMS 

16 

19 

Architecture Cost Risk 

13 

13 

Dependability 

9 


Mission Growth Potential 

6 


Alternate Access 

5 


Resiliency 

4 


Availability 

4 


Environment 

3 

4 

Launch Schedule Confidence 


8 

Total, % 

100 

100 
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The second method, called the trade-off method, involves comparing attribute 
scores directly, one to one with each other, and determining the relative weightings. 
The intent of the trade-off method is to find a set of equally preferred outcomes such 
that the decision-maker is indifferent between them. An example is shown below 
in Figure 3.2. 1.3-2 for the trade-off between the two attributes of funding profile 
(cost) and crew loss events (safety). The decision-maker is initially offered the choice 
between A (the best outcome on safety paired with the worst outcome on cost) and B 
(the worst outcome on safety paired with the best outcome on cost). The decision- 
maker's choice will depend on the two considerations. First, which attribute is 
more important to the decision-maker. Second, what is the range (difference 
between the worst and best outcomes) for each attribute. In this example, the 
decision-maker chose B and continued to prefer the B choices until the best outcome 
on the cost axis was diminished to B'". At that point, the decision-maker was indif- 
ferent between A (the best outcome on safety paired with the worst outcome on cost) 
and B"' (the worst outcome on safety and a cost defined by B'"). 


A 



Funding Profile 


Figure 3. 2. 1.3-2.- Example attribute trade-off curve. 


Since the decision-maker is indifferent between these two pairs of outcomes, the 
sum of their weighted utilities must be equal since, 

(cost wt)*(utility of A cost) + (safety wt)*(utility of A safety) 

= (cost wt)*(utility of B"' cost) + (safety wt)*(utility of B"' safety). 

This indifference equation can be solved for the relative weights between cost and 
safety by setting all the worst outcome scores for each attribute equal to zero and the 
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best outcome scores equal to one. Since the decision-maker is interested in the 
relative desirability of the various choices (architectures), a relative scoring method 
with a zero-one convention for the worst and best outcomes simplifies the analysis. 
The utility curve between these two points can assume any shape. Typically, when 
the outcomes are certain and the Government is the decision-maker, the most 
practical utility for the intermediate outcomes is linear. A linear utility curve 
means that each additional dollar spent or the next crew loss is just as undesirable as 
the previous one. 

The utility scores for the above outcomes are substituted in the above equation. For 
the worst cost outcome (utility of A cost) and the worst safety outcome (utility of B"' 
safety), the utilities are both 0. For the best safety outcome (utility A safety), the 
utility is 1. If the utility scores for cost between worst and best is linear, then the 
utility for B"’, which is halfway between the worst and best, is .5. The above 
equation reduces to the following: 

(cost wt) * 0 + (safety wt) * 1 = (cost wt) * .5 + (safety wt) * 0 

( safety wt)/ (cost wt) = .5 

This trade-off relationship indicates that the safety attribute is one-half as important 
as the cost attribute, given these specific ranges for each attribute. 

Thus, the tradeoff assessment between pairs of attribute outcomes reveals their 
relative weights. The rationale for the weights is based on specific preferences for 
different sets of attribute outcomes. The trade-offs and the reasons for them are 
based on the decision-maker's inherent preferences for specific combinations of 
outcomes. Both the preferences and rationale can be communicated and discussed, 
and the audit trail of the decision-makers thinking is preserved for future reference. 

The number of tradeoff assessments required, of the type shown in Figure 3.2.1. 3-2, 
to compute the relative weights between N attributes is N-l tradeoff pairs. Typically, 
one attribute is selected as the reference attribute and the tradeoff relationship is 
found between it and all the others. The most important attribute is generally used 
as the reference, and for many evaluation studies of this type the most important 
attribute is often cost. As a consistency check, other attributes were used as the 
reference in the tradeoff as a partial consistency check. 

A comparison of weightings resulting from this method and the direct method is 
given in Table 3.2. 1.3-2. Notice that, except for the slight lowering of the PMS 
weighting, the results are very similar. The basis of this study uses the direct 
method. These weightings are a good measure of the relative importance of the 
major attributes that should be used in judging human launch systems. 

In the final analysis, the only attribute weightings that matter are those that the 
NASA administrators chooses (the customer). The process he uses to combine the 
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attributes will also affect his choice of the next human transportation system. 
Therefore, while the HTS team believed that the analytical/mathematical method it 
developed was useful in identifying trends and drivers affecting the architecture 
rankings, the results of this method are not reported in the findings section (3.3.12). 
What will be reported are the major attribute values and key drivers effecting those 
values that the HTS team believes will affect a customers decision. 


TABLE 3.2. 1.3-2 - COMPARISON OF ATTRIBUTE WEIGHTING METHODS 


Attribute 

Direct Method 

Trade-off Method 

Funding Profile 

27 

30 

Human Safety 

29 

33 

PMS 

19 

11 

Architecture Cost Risk 

13 

11 

Launch Schedule Confidence 

8 

8 

Environment 

4 

7 

Total, % 

100 

100 

















3.2.2 Funding Profile 


This section contains the definitions of the Funding Profile attribute and its 
measures, a discussion of the process by which the architecture cost estimates were 
generated, the HTS cost analysis groundrules and assumptions, and a discussion of 
the utility curves for this attribute. 


3.2.2. 1 Definition 

The Funding Profile attribute is evaluated through the consideration of two 
subattributes. Total Architecture Cost (TAC) and Peak Year Funding (PYF). The 
definition of Funding Profile adopted by the NIT is: 

The sum of the system costs of an architecture, by year, incurred over 
the time period of study interest (1992-2020), to deliver all missions 
flown from 1998 through 2020. The costs per year include the non- 
recurring and recurring element/ system costs associated with 
providing the capability to satisfy the mission model as defined in the 
particular 'If' scenario of interest. 

The subattributes of TAC and PYF are defined as: 

The TAC is the total architecture cost over the life of the study, 
including the cost of unreliability. The PYF is the dollar amount in the 
year of peak (maximum) costs. 


3.2.2.2 Measurement of Attribute 

The following describes the methodology used to develop the cost 
data used for the funding profile of each architecture. 

3.2.2.2.1 Cost analysis data flow - The cost analysis was carried out as an integrated 
process, requiring key inputs supplied by each of several different NIT groups 
developing and measuring different architecture attributes. Resulting architecture 
cost estimates were passed to the AET for final processing and inclusion in the 
overall architecture scoring process. Figure 3.2.2-1 outlines the Funding Profile 
attribute data flow. 

The manifesting lead supplied yearly flight rates and system IOC dates for each 
system. The operations lead defined architecture asset requirements, including 
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Figure 3.2.2-1. Funding profile attribute architecture cost analysis data flow. 


ground facilities and reusable hardware production quantities (if hardware 
quantities were driven by ground processing times instead of flight rates). The 
system data leads provided system cost input data for each system, including the 
non-recurring costs for DDT&E and facilities, as well as flight-rate-sensitive 
recurring production and operations cost inputs. These were in the form of 
Theoretical First Unit (TFU) costs plus learning and rate curves, and/or fixed per 
year and variable per flight costs. As part of their inputs, system data leads also 
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provided year-by-year spread factors for each cost element to reflect the year in 
which costs were incurred. 

The architecture cost "model" utilized to generate the architecture level cost 
estimates was a series of electronically linked Excel computer spreadsheets, each 
calculating some portion of TAC. A separate model of linked spreadsheets was 
developed for each architecture, modifying the spreadsheets to tailor them to reflect 
the specific systems included in each unique architecture. Figure 3.2.2-2 illustrates 
the general input-process-output connections within the cost model. 

3 2.2.2.2 Cost analysis definitions .- The TAC of an architecture includes the total 
cost of all transportation systems in the architecture, where total system life cycle 
cost is the sum of non-recurring, recurring, and transportation system failure costs 
as defined below 

The TAC for each architecture system includes all applicable Work Breakdown 
Structure (WBS) systems and subsystems for the following phases of the system s 
life cycle: 

• Non-Recurring - Design, Development, Test, and Evaluation (DDT&E), Non- 
Recurring Production, Facilities, Pre-Planned Productivity Improvement (P3I) 

• Recurring - Recurring Production, Operations 

• Transportation system failures 

The WBS used is shown in Table 3.2.2-1. 

DDT&E includes the cost of the following for each applicable WBS item for new 
vehicle development and existing vehicle modifications consistent with a Full Scale 

Development program: 

• Hardware (Ground and Flight) - design, prototype manufacturing and assembly, 
test and evaluation, integration of all vehicle and ground support equipment 
(GSE)/ peculiar support equipment (PSE) WBS items to next higher assembly 
through system level integration, systems engineering, program management 

• Software (Ground and Flight) - systems analysis (design), coding, test and debug, 
system integration, validation and verification, and program management 

Facilities costs include architecture and engineering, construction of facilities (C of F 
or "brick & mortar"). Real Property Installed Equipment, and site activation for any 
new, additional, or modified production, launch, flight, or associated facilities. 
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Figure 32 . 2 - 2 - Architecture cost modeling process. 
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TABLE 3.2.2.-1- HTS WBS 





LEVEL 
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Subsystem 
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' 7.2 VEHICLE SEGMENT 







1. 2.1.1 

IAT 






1. 2.1.2 

Structures 






1.2. 1.3 

Separation Sys 






1.2. 1.4 

Recovery A Landing Sys 






1.2. 1.5 

Thermal Protection 






1.2.1. 6 

Main Engine Prop 






1 .2.1.7 

Auxiliary Propulsion 






1 .2.1.8 

Propulsion Feed Sys 






1.2. 1.9 

Power Gen A Distrib 






1.2.1.10 

Control System 






1.2.1.11 

Avionics 

1 





1.2.1.12 

Envir Ctl A Ule Supt 






1.2.1.13 

Toolng 

! 





1.2.1.14 

Support Equipment 

* 





1.2.1.15 

Spares A Repair Parts 






1.2.1.16 

Major Overhauls 
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13 GROUND SEGMENT 
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1.3.1 FACILITIES A EQUIPMENT 

i 





1. 3.1.1 

Launch Pad 

i 





1.3. 1.2 

Vertical Process Facfl 






1.3.1 .3 

Horizontal Proc Facil 






1.3.1 .4 

Launch Ctl Cntr 

I 





1 .3.1.5 

Mission Control Ctr 

_ 





1.3. 1.6 

Comm Network 

-= 





1.3. 1.7 

Test Facilities 






1.3. 1.8 

Manufacturing Fadl 
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Other FaciBties 










1.0 TRANSPORTATION SYSTEM - COMMON SYSTEMS 

“ssesaiis&S:.' i jwiaog^ 

7.1 PROGRAM SEGMENT 

1 1 . 1 .1 Program Management & Support 


Subsystem Deiinit.ons (As Applicable - Hems Listed - Examples Oot fl_ 


t . 1 .2 Systems Engineering & Integration 
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Architecture 




I 

System 


’ \ 4,1 SYSTEM TEST & EVALUATION 


t 


n 

Segment 


HI 

Element 


IV 

Subsystem 


jl.4.1.1 Development Tests 
j 1.4. 1.2 Operational Tests 
1.4.2 SYSTEM OPERATIONS A SUPPORT 
1 1. 4.2.1 Training 


1.4. 2.2 Launch Operations 


1 .4.2.3 Fight Operations 


1 T SOFTWARE SEGMENT 

‘ 1.5.1 FLIGHT SOFTWARE 


1. 5.2.1 

Operating System 

1. 5.2.2 

Guidance, Nav, A Ctl 

1. 5.2.3 

Subsystems Mgt 

1. 5.2.4 

Comm/T elemetry 

1. 5.2.5 

Other 


1,5.2 GROUND SOFTWARE 

1. 5.3.1 GSE Operations 

1. 5.3.2 

1. 5.3.3 

1.5. 3.4 


Pre Launch Ops 
Launch Management 
Post Launch Ops 


Other 

v vw- -> v. y^v ... . . . r . *.■ 


1. 5.3.5 
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2.0 to n.O TRANSPORT AT10N SYSTEM - INDIVIDUAL SYSTEMS . ^ . .. _ 
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stages, plus shrouds, crew modules, reusable cargo carriers 
Element Integration, assembly, & test 
Tanks, Adapters, Skins. Wings, Empennage. Fuselage 
Separation systems. Ordnance, Disconnects 
Parachutes. Landing Gear 
Tries, Blankets, MLI, Carbon/Carbon, SOFI 
Liquid engines, Solid motors 
TVC. RCS, OMS 

Feed inos. Fill & drain. Propellant Utilization. Pressurization 
Batteries, Fuel Cells. Cables A harnesses, Power Distrib Units 

Hydraulics, EMAs t „ , 

GNAC, Comm A Track. Data Process. Instrumentation, Telemetry 
Range Safety, Aclive thermal control 
Atmosphere Ctl, Consumables A waste mgt. Airlock 
Design manirfaciure, and maintenance of production rate tooling 
Systeni-pecuflar (or common for 1 .0) ground support equipment (GSE) 
Sum of aH element subsystem spares 


For all ladlities: Non-Recurring - Architecture A Engineering 
(AAE), Construction ol Facility (C of F), Site Activation (SA); 
Recurring - Facility maintenance 


Government Owned/Cont factor Operated (GOCO) only 
{Whatever olhe r f adfiilesa^^ 


Subsystem Definitions (As AppScaWe - Items Listed - Examples Only) 
Subsystems * aerothermal, acoustic shock A vibration, fluids 
Integrated system ground, fight 


Start-up training program for personnel associated wish oper- 
ations, recurring crew and fight controller training 
Vehicle launch processing. Cargo integration, Fight-to-flight re- 
furbishment. Base ops support. Liquid propellants. Landing A 
recovery ops, Unscheduled maintenance 
Ffight planning A design. Real-time mission control. Analytical 
pay toad Integration Crew -operations _ 


For all software: Non-Recurring - System design, coding, test A 
debug, independent Verification A Validation; 

Recurring - Software maintenance, Fiight-to-fSght reconfiguration 




. ' y »•* 

For each individual system in an architecture 

; . . /. . -0 • . - - 
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Non-Recurring Production includes the cost of the following for each applicable 
WBS item: ^ 

• Tooling - design and manufacture of production-rate tooling. 

• Initial Training - start-up training for all personnel associated with recurring 
phase activities, such as production manufacturing personnel, ground 
operations technicians, and flight controllers. 

• Initial Spares - initial lay-in of vehicle spares and repair parts. 

• Prototype Refurbishment - cost associated with refurbishing a development 
prototype unit for production use. 

• Support Equipment Acquisition - fabrication, assembly, and initial lay-in of 
spares and repair parts of GSE, including common and peculiar equipment. 

Preplanned Productivity Improvement includes continuing modification and 
upgrade programs. For example, for Space Shuttle, these would include: an 
interface monitoring unit (IMU), general purpose computer, and auxiliary power 
unit (APU) upgrades. Extended Duration Orbiter (EDO), and Space Shuttle main 
engine (SSME) turbopump redesign. 

Recurring Production includes: 

• Hardware - procurement, fabrication, assembly, integration and checkout of all 
reusable and expendable vehicle flight hardware, program management and 
manufacturing support activities (tooling and plant maintenance, scheduling, 
quality assurance, etc.), transportation to launch site, major off-line overhauls of 
reusable vehicles, and vehicle spares and repair parts. 

Recurring Operations includes: 

• Launch - hands-on launch vehicle processing and integration, payload-to-vehicle 
cargo integration, flight-to-flight refurbishment and checkout (reusables), launch 
processing support activities (ground software maintenance, launch facility and 
GSE maintenance/ recurring spares, base operations support, and program 
management), liquid propellants, landing and recovery ops, and unscheduled 
maintenance operations and support. 

• Flight - flight planning and design, flight-to-flight mission software 
development and reconfiguration, flight software simulation and test, crew and 
flight controller recurring training, real-time mission control, analytical payload 
integration, systems engineering and integration, program management, crew 
operations, base operations support, and communications network support. 


3 . 2-17 


Rev E 



• On-Orbit - on-orbit space transportation operations and support activities. 

Transportation System Failure costs include the cost of vehicle replacement and 
reflight. The number of failures was determined by multiplying the individual 
element or system total flights in the architecture by one minus the element or 
system's PMS. This number was used to determine the number of reflights to be 
included in the cost of unreliability. This cost was estimated using the variable 
portion of operations cost. In the case of expendable systems, this cost also included 
the cost of an additional vehicle. The production cost of the additional expendable 
vehicles were costed at an average or nominal production rate for the architecture. 
In the case of reusable vehicles, the number of crew loss events per element or 
system per architecture was used to determine the number of replacements of 
reusable vehicles which was added to the variable operations cost. Cost did not 
include lost payloads, accident investigation and resolution, added cost during 
backlog recovery, or cost of lost opportunities. 

3.2.2.23 Cost analysis groundrules and assumptions - All costs are reported in 
constant 1992 dollars. Data normalization to 1992 dollars and any HTS program 
requirements to provide escalations of architecture funding profiles to inflation- 
adjusted, then-year dollars is accomplished using the Code BA NASA New Start 
Inflation Index escalation rates published May 13, 1991, shown in Table 3.2.2-2. 


Present value discounting can be accomplished using the AET. The discount rates 
are used on yearly funding streams of escalated (using the above yearly rates), then- 
year dollars. (The study team chose to look only at the constant dollar costs for 
analysis and comparison of architectures.) 

The TAC assessment time horizon for all architectures is 1992 through 2020, 
considering the non-recurring and recurring cost to support all missions flown from 
1998 through 2020. The costs for missions flown from 1992 through 1997 are not 
considered part of TAC. As an exception, in the event architecture assets, including 
ground facilities or new reusable hardware elements (e.g., launch pad or Space 
Shuttle Orbiter) are required to support flights from 1992 through 1997, and are also 
required subsequently to support post-1997 flights, the cost to provide those assets is 
recognized in the years appropriate to support the pre-1998 flights. 

Cost wraps - with the exception of existing systems, whose costs were assumed to 
inherently include wraps, all architecture estimates provided to the architecture 
evaluation tool did not include wrap factors for contractor fee, government support, 
and contingency. The wrap factors are applied to the cost estimates within the AET. 
Agreed upon baseline wrap factors are contained in Table 3.2.2-3. 

Transportation system cost data inputs were supplied to the funding profile attribute 
integrator using standard format cost data input sheets (see Table 3.2.2-4). 
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TABLE 3 . 22 - 2 .- CODE BA NASA NEW START INFLATION INDEX 




1991 

1992 

1993 

1994 

1995 



4. OX 

5.0* 

4.9* 

5.2X 

5.3* 



l.WO 

1.050 

1 .049 

1.052 

l .051 

MCM 

1959 

6.531 

6.857 

7.193 

7.567 

7.988 

F ICM 

I960 

6.262 

6.575 

6.897 

7.255 

7.640 

ficw 

1W1 

6,087 

6.371 

6.883 

7.010 

7.403 

mcm 

1962 

5.854 

6.126 

6.426 

6.760 

7.118 

FICW 

\m 

5 .637 

5.919 

6.209 

6.531 

6.878 

f 1CW 

1964 

5.394 

5.644 

5.W1 

6.250 

6.561 

new 

mi 

5.217 

5.477 

5.746 

6.W5 

6.365 

new 

1966 

4.921 

5.167 

5.421 

5.703 

6.005 

new 

1967 

(.691 

4.926 

5.167 

5.436 

5.724 

MOM 

1968 

4.451 

4.674 

4.903 

5.158 

5.431 

F1CW 

m? 

(.211 

4.422 

4.638 

4.679 

5.138 

FICM 

1970 

3.939 

4.136 

4.339 

4.565 

4.808 

FICW 

1971 

3.708 

3.691 

(.082 

4.294 

4.522 

FICM 

1977 

3.508 

3.681 

3.882 

4.082 

4.278 

MON 

1973 

3.317 

3.483 

3.653 

3.643 

4.047 

MOM 

1974 

3.094 

3.249 

3.(08 

3.585 

3. 775 

MCM 

1971 

2.793 

2.93 2 

3.076 

3.238 

3.407 

FICM 

1974 

2.562 

2.690 

2.822 

2.989 

3.126 

MCM 

10 

2.509 

2.635 

2.764 

2.908 

3.082 

FICM 

1977 

2.313 

2.428 

2.547 

2.680 

2.622 

FIOH 

1978 

2.1(5 

2.253 

2.383 

2.(88 

2.618 

FICM 

1979 

1.959 

2.057 

2.158 

2.270 

2.391 

FICM 

I960 

1.770 

1.655 

1.949 

2.051 

2.159 

FICM 

1981 

1.607 

1.688 

1.771 

1.683 

1.961 

FICM 

1987 

1.(91 

1.548 

1.642 

1.728 

1.819 

MCM 

1983 

1.(01 

1.472 

1.544 

1.624 

1.710 

FICM 

1984 

1.330 

1.398 

1.465 

1.541 

1.622 

FICM 

1985 

1.288 

1.350 

1.416 

1.490 

1.569 

FICM 

1988 

1.249 

1.311 

1.375 

1.447 

1.523 

MCM 

1987 

1.199 

1.259 

1.321 

1.390 

1.463 

FICM 

1988 

1.139 

1,198 

1.255 

1.320 

1.390 

FICM 

1989 

J.W7 

1.U1 

1.197 

1.259 

1.326 

MCM 

1990 

l.WO 

1.092 

1.146 

1.205 

1.269 

MCM 

1991 

1 

1.050 

1.101 

1.159 

T.220 

MCM 

1992 


1 

1.049 

1.104 

1.162 

F«CM 

199J 



1 

1.052 

1.108 

MCM 

1994 




1 

1.053 

FICM 

1995 





1 

MCM 

1996 






MCM 

1997 






FICM 

1996 







FICM IW 
fich 2000 
ficm 200 l 
ficm 2002 

FKW 2001 

new 200; 

F I Cm 20CS 


5/25/91 


1996 

1997 

1996 

1999 

2000 

2001 

5.0* 

5.2* 

5.2X 

5.4X 

5.6X 

5. OX 

1.050 

1.052 

1.052 

1.054 

1.054 

1.050 

6.367 

8.802 

9.260 

9.760 

10.306 

10.822 

8.022 

6.439 

8.676 

9.357 

9.881 

10.375 

7.773 

8.177 

8.603 

9.067 

9.575 

10.054 

7.474 . 

7.863 

6.272 

6.716 

9.207 

9.487 

7.221 

7.597 

7.992 

8.424 

6.695 

9.340 

6.911 

7.270 

7.646 

6.061 

8.512 

6.938 

6.683 

7.0J1 

7,396 

7.796 

8.232 

8.644 

6.305 

6.633 

6.976 

7.355 

7,766 

8.155 

6.010 

6.323 

6.652 

7.01 1 

7.404 

7.774 

5.703 

5.999 

6.311 

6.652 

7,024 

7.376 

5.395 

5.676 

5.971 

6.293 

6.646 

6.978 

3 .047 

5.309 

5.565 

5.687 

6.217 

6.527 

4.746 

4.995 

5.2S4 

5.536 

5.648 

6.141 

4.(92 

4.725 

4.971 

5.239 

5.533 

5.609 

4.2(9 

4.470 

4.703 

4.957 

5.234 

5.496 

3.964' 

4.170 

4.367 

4.624 

4.683 

5.127 

3.578 

3.764 

3.959 

4.173 

4.407 

(.627 

3.282 

3.453 

3.632 

3.829 

4.043 

4.245 

3.215 

3.382 

3.558 

3.750 

3.960 

4.158 

2.963 

3.117 

3.279 

3.456 

3.650 

3,632 

2.749 

2.891 

3.042 

3.206 

3.366 

3.555 

2.510 

2.641 

2.776 

2.928 

3.092 

3.246 

2.267 

2.34$ 

2.509 

2.645 

2.793 

2.953 

2.059 

2.167 

2.279 

2 ; *02 

2.537 

2.664 

1.910 

2.010 

2.114 

2.226 

2.353 

2.471 

1.796 

1 .849 

1.967 

2.094 

2.212 

2.322 

1.704 

1.792 

1.885 

1.967 

2.096 

2.203 

1.646 

1.733 

1.623 

1.922 

2.029 

2.111 

1.600 

1.683 

1.770 

1.866 

1.970 

2.049 

1.537 

1.616 

1.700 

1.792 

1.893 

1.987 

1.459 

1.535 

1.615 

1.702 

1.797 

1.882 

1.392 

1.465 

1.541 

1.624 

1.715 

1.801 

1.332 

1.402 

1.475 

1.554 

1.641 

1.723 

1.261 

1.348 

1.416 

1.494 

1.578 

1.657 

1.220 

1.264 

1.350 

1.423 

1.503 

1.528 

1.163 

1.224 

1.287 

1.357 

1.433 

1.504 

1.106 

1.16$ 

1.224 

1.290 

1.342 

1.430 

1.050 

1.105 

1.162 

1.225 

1.293 

1.358 

1 

1.052 

1.107 

1.166 

1.232 

1.293 


1 

1.052 

1.109 

1.171 

1.229 



1 

1.054 

1.113 

1.149 




1 

1.056 

1.109 


1 1.050 

1.000 


2002 

2003 

2004 

2005 


5. OX 

5. OX 

5. OX 

5. OX 


1.050 

1.050 

1.050 

1.050 


11.343 

11.931 

12.527 

13.154 

IV*, 9 

10.694 

11.439 

12.011 

12.611 

I960 

10.556 

11.084 

11.638 

12.220 

1961 

10.150 

10.658 

11.191 

11.750 

1962 

9.607 

10.297 

10.612 

11.353 

1963 

9.385 

9.654 

10.347 

10.864 

1W 

9.076 

9.530 

10.007 

10.307 

1965 

6.562 

8.991 

9.440 

9 912 

you 

6.162 

6.571 

8.999 

9.449 

196 7 

7.744 

8.132 

8,533 

8.V65 

1968 

7.377 

7.693 

8.078 

8.462 

1969 

6.854 

7.196 

7.556 

7.934 

1970 

6.445 

6.770 

7. 108 

7. 464 

1971 

6.100 

6.405 

6.725 

7.061 

1972 

5.771 

6.059 

6.362 

6.681 

1973 

5.383 

5.652 

5.935 

6.232 

19/4 

4.859 

5.10? 

5.357 

5.624 

1975 

4.457 

4.680 

4. 914 

5. l&O 

1976 

4.366 

4.584 

4.813 

5.054 

10 

(.024 

4.225 

4.416 

(.655 

1977 

3.733 

3.919 

4.115 

(.321 

1978 

3.409 

3.579 

3,758 

3.946 

19 TV 

3.079 

3.213 

3.395 

3.565 

1V60 

2.797 

2.917 

3 . 06 J 

3.236 

1961 

2.594 

2.774 

2. VA 

3.003 

1982 

2.438 

2.560 

2.688 

2.821 

1953 

2.313 

2.429 

2.551 

2.676 

1984 

2.237 

2.349 

2.467 

2.590 

1985 

2.172 

2.281 

2.195 

2.515 

1986 

2.067 

2.191 

2.301 

2.416 

1987 

1.962 

2.081 

2.185 

2.294 

1588 

1.891 

1.985 

2.085 

2.18? 

1989 

1.609 

1.900 

1.995 

2.095 

1990 

1.740 

1.827 

1.918 

2.014 

19? 1 

1.657 

1.740 

1,827 

1.918 

19?? 

1.560 

1.659 

1.742 

1.829 

19? 3 

1,502 

1.577 

1.655 

1 .738 

1994 

1.426 

1.497 

1.572 

1.651 

1995 

1.358 

1.426 

1.497 

1.572 

1996 

1.291 

1.355 

1.425 

1 . 494 

1997 

1.227 

1.268 

1.353 

1.421 

1978 

1.164 

1.222 

1.284 

1.348 

IV?? 

1.103 

1.158 

1.216 

1 . 276 

2000 

1.050 

1.105 

1. 158 

1.216 

?O01 

1.000 

1.030 

1 . 10J 

1.158 

200? 


1.000 

1.050 

1.103 

2003 



1 .000 

1.050 

?00( 




1.000 

2005 
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TABLE 3.2.2-3- BASELINE WRAP FACTORS 


Element 



Fee * 

10% 

10% 

Program Support ** 

20% 

10%/ 15% # 

Reserves *** 

35% 

20% 

HQ Taxes **** 

2% 

2% 

Combined Total Wrap Factor 

80.4% 

47.4%/54.0% # 


Notes: 

* Percentage shown Is of Prime Cost. 

w Percentage shown is of Total Prime Cost with Fee. Includes management and integration. 
*** Percentage shown is of Total Prime Cost with Fee + Program Support. 

**** Percentage shown is of Total Prime Cost with Fee. 

# With No Primary Engines /With Primary Engines 


The Vehicle Cost Inputs Summary sheets were used as the cost data input to the 
architecture cost model. It was the minimum system data required to conduct an 
architecture cost analysis. It included top level non-recurring cost estimates for 
DDT&E, Non-Recurring Production, P 3 I, and Facilities, as well as recurring element 
estimates in a flight-rate sensitive format for TFU and learning and rate curves, 
and/or fixed cost per year and variable cost per flight. 

It also included per year cost-spread factors for each element, and other pertinent 
information such as elements common with other systems, critical technologies, 
facility dwell times, and reusable hardware useful life. 
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TOTAL SPREAD FACTORS 


TABLE 3.2.2-4.-VEHICLE COST DATA INPUT SUMMARY SHEET - SAMPLE 
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$ 1,366 $714 $497 $389 $324 $280 



Vehicle-specific assumptions of the following parameter values were provided by 
system leads on a system-by-system basis: 

• Design-useful life and flights per major overhaul (reusables). 

• Ground and flight test program definition (number of prototypes, etc.). 

• Schedules - IOC's, development and production schedules. 

• Operations and personnel shifting assumptions. 


The following costs are not included in architecture TAC estimates: 

• Technology development not conducted directly as part of a system's Phase C/D 
(FSD) program. 

• Phase A/B concept design and demonstration and validation activities. 


• Payload acquisition and launch preparation cost (except for transportation-related 
payloads). 

• Previous sunk costs for existing programs. 

• SSF Acquisition and Operations cost, except for additional cost which might be 
incurred to support transportation missions. 

• Advanced solid rocket motor (ASRM) development. 

The results of the Funding Profile Attribute cost analyses were passed to the AET, 
where top level wrap factors for government support, contractor fee, and 
contingency were applied. An example of the summary Funding Profile data 
available from the AET is shown in Figure 3.2.2-3. The wrapped values of TAC and 
PYF, expressed in constant 1992 dollars, were used within the AET to generate the 
overall Funding Profile attribute score. 


3.2.2.3 Funding Profile Utility Curves 

Linear utility curves were developed for use in the AET to score the various 
architectures with respect to their costs. Each architecture was examined, by HTS 
Mission Model "If" scenario to determine the minimum and maximum values of 
both TAC and PYF within the given "If". For each subattribute, the architecture(s) 
with the maximum values of TAC or PYF were assigned a score of zero for that 
subattribute. Conversely, the architecture(s) with the minimum values of TAC or 
PYF were assigned a score of one. The subattribute scores for all other architectures 
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in the "If" were determined through linear interpolation, based on their values of 
TAC and PYF relative to the minimum and maximum values. 

The final architecture score was obtained by combining the equally weighted scores 
for TAC and PYF (essentially averaging the two scores) to obtain a single score 
between zero and one. Since it was unlikely that a single architecture would have 
both the lowest or highest score in both TAC and PYF, the range of combined scores 
would most likely be greater than zero and less than one. For this reason, the 
combined scores were then forced into a range from zero to one through a similar 
linear interpolation process to that used for the subattribute scores. Again, the 
highest combined score was given a one, and the lowest a zero. This then assured 
that at least one architecture in each "If" scored a one or a zero. 



Year 

Figure 3.2.2-3 - Example of the funding profile data. 
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3.2.3 Human Safety 


The indusion of safety as a comparative system attribute was based on the 
perception that adequately providing for the well being of humans assodated with 
space flight endeavors has been, and will remain, an important consideration to the 
customer (as well as the general public). Not only should a system exhibit an 
acceptable level of safety as a moral and legal obligation, but as a means of sustaining 
public confidence and hence congressional support. From the outset, it is 
acknowledged that, from a systems engineering perspective, system safety could be 
measured in terms of cost; the impact of a major mishap or loss has significant 
program cost (hardware replacement and repair, schedule slides, insurance, etc.) as 
well as more indirect costs assodated with loss of prestige, public confidence, and 
credibility. 


3.2.3.1 Definition 

The definitions of the term safety vary depending on the scope of the boundaries of 
a system. In the broadest sense, the definition might best be: 

Safety is freedom from risk to people 
and property both public and private. 

This represents the ultimate goal of safety; however, the best that can ever be done is 
to reduce that risk (through design, testing, and operational procedures) to some 
agreed upon acceptable level, as risk can never be truly eliminated from any 
endeavor. It is unlikely that an architecture will be rejected solely on the basis of 
safety. It is possible that less than an optimum level of safety will be deemed 
acceptable because of superior mission or cost performance (the Space Shuttle is a 
typical example). This is acceptable as long as it done from a position of informed 
consent and a clear understanding exists of the potential effects resulting from the 
additional risk. 

For the purposes of this study, the NIT consensus was to limit the scope of safety to 
reflect the fact that some of the costs of a failure are covered under other attributes. 
Based on group discussions, the HTS definition of safety is as follows. 

Safety is the measure of risk in terms of 
human loss caused by the elements and/ or 
operations associated with a given architecture. 

Human loss is defined as death (or incapacitating injury) of flight personnel. No 
attempt was made to determine loss of the general populace that would be 
associated with a catastrophic event involving a major population center (such as a 
crash in Orlando or a major chemical spill). This definition is also meant to exclude 
the impact on property. 
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The exclusion of ground personnel from the definition of safety was a point of 
much discussion. Basically, it was thought that it would be extremely difficult to 
measure losses of ground personnel, requiring Monte Carlo type simulations of 
ground operations for systems which in some cases are strictly hypothetical 
Assuming the losses could be calculated, the question remains, "What is the impact 
personnel losses as compared to flight personnel (astronauts) losses?" 
While it is probably true that flight crew losses result in larger cost and schedule 
impacts, can or should a differentiation be made? The approach was not to consider 
ground personnel and to assert that any endeavor or industrial activity involves 
accidents and losses, not just activities related to spaceflight. To check this assertion 
recent accident rates for space launch operations personnel and typical aerospace 
industry were compared. For KSC, (contractor and government personnel) an 
average of 0.89 cases and 13.0 lost days per 100 workers is typical. The corresponding 
figures for the aerospace industry were 4.5 cases and 114.7 lost and restricted days. 

The establishment of the level of necessary and acceptable risk is a formidable task 
and is one not to be determined in this study. In other aerospace systems, a Military 
,Tu ° n ? r Federal Aviation Administration Federal Airworthiness Regulation 
would be used as a basis for identifying acceptable risk. For space systems, the nation 
still seems a long way from such guidelines. Even the man-rating standards now in 
development seem unlikely to assuage the public in the event of the loss of the 
astronauts. In any case, once a level of acceptable risk has been defined, all systems 
can be simply evaluated - either they conform or they do not conform. There is no 
such thing as safe, safer, and safest", only safe or unsafe. 


3 2.3.2 Measurement of the Attribute 

The approach taken to compare safety was to calculate a risk index for each proposed 
element. Each architecture, in turn, would sum the indices for the elements it uses 

to arrive at a total probable number of flight personnel losses over the duration of 
the architecture. 

Inflight emergencies can be caused by any number of failures and often involve 
complex system interactions; some of these emergencies will require contingency 
procedures. Because it was impractical to model all the possible failure modes and 
effects, six major groupings of typical failures were evaluated for each flight phase 
or each system. These categories are meant to define the primary cause of the flight 
emergency - in many historical cases, the failures often involved elements from 
several categories. For example, the primary cause of the Challenger accident could 
be used as a structural failure of the aft solid rocket booster (SRB) /external tank (ET) 
attachment; subsequent rupture of the ET lead to aerodynamic breakup, loss of 

control, and some degree of explosion. The six categories considered in this study 
were defined as follows: 3 
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• Explosion - a rapid, violent release of energy that is characterized by large change 
in pressure and temperature. Hazards to crew members result from 
overpressure to structures and human tissues, flash heating, and shrapnel 
impacts. 

• Fire - an energy release characterized by elevated temperatures. In the process of 
burning, oxygen available to the crew can be consumed, while at the same time, 
hot gases, often toxic to humans, are generated. 

• Loss of Control - failure to maintain attitude and/or velocity that could place the 
crew at risk. Hazards to the crew would occur because of overstress of structure 
(aerodynamic or aerothermodynamic), acceleration or rotation rates in excess of 
human tolerance, or placement in an unrecoverable locale (high orbit or Arctic 
waters). 

• Damaged Vehicle - failure induced by external sources that compromise the 
integrity and functionality of the vehicle. 

• Benign Failure - a degradation in system performance that is characterized as 
presenting no immediate life-threatening situation. Any failure that will 
ultimately necessitate some contingency procedure represents an increase in 
overall risk. This category includes all failures that do not fit in one of the other 
five categories. 

• Hazardous Environment - a failure that creates a detriment to human health 
within the crew enclosure. Hazards include toxic substances, loss of pressure, or 
temperature extremes. 

The method used to calculate risk involves a high-level reliability assessment and a 
statistical (or postulated in new systems) grouping of the major types and effects of 
failures. The reliability assessment uses the output from the PMS attribute; that is, a 
reliability value for each distinct and significant flight phase. When a failure event 
occurs (Probability of Failure = 1- PMS), there is a chance that any crew can survive 
the short term effects immediately attributable to the failure condition. This 
Probability of Survival (Ps) is determined for each of six major failure categories 
through analogy to historical systems and through assessment by a group of safety 
experts. Subsequently, for the cases where the crew has survived the failure, it is 
assumed some abort or contingency procedures would be initiated. It is assumed 
that throughout this attribute that the entire crew realizes the same fate - there is no 
accounting of partial crew losses. Depending on the system design, flight regime, 
and the nature of the failure, there will be some probability of a successful abort - 
defined as the point where the crew has arrived on land alive and with no 
incapacitating injuries. This Probability of Abort (Pa) is also determined for each of 
six major failure categories by historical analogy and assessment by a group of safety 
experts. 
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To determine the probability of a crew loss event, the probabilities of unsuccessfully 
surviving and aborting are multiplied together with the relative percentage of 
occurrence (F, in %) of the major failure category, and then summed to produce a 
single risk index (called Pd) for each flight phase. Mathematically: 

6 

Pd = 1 - £ { ( F / 100 ) * ( P s )i * ( P A )i } 
i=l 

where "i" is the failure category. 

An example of how a benign failure can effect safety is found in the case where an 
ET fails to separate from the Space Shuttle orbiter. There will be no immediate 
impact to the mission or to the safety of the crew; however, some contingency 
procedure will need to be executed to successfully reenter the orbiter, and that 
procedure may not be wholly successful, resulting in crew loss. 

Figure 3.2.3.2-1 is a sample worksheet of how the Pd value is derived; all the 
worksheets can be found in Appendix B. Another way to look at the value of Pd is 
to use it as a ratio of loss events over the total failure events. The values for P D are, 
in general, conservative; however, since all the elements were developed with the 
same thinking and the same experts, the relative comparison should be valid. 

For the entire mission, the Pd by phase is multiplied by the value of unreliability of 
that phase, and multiplied across all phases to arrive at a net Probability of Loss (Pl) 
defined as: 

k 

Pl = l-[n{P M Sj + (l-PDj)*(l-PMSj>}] 

H 

where k is the total number of flight phases. 

The value of P D takes into account (qualitatively) the duration of the flight phase 
(exposure to risk), the flight environment (altitude, q, temperature, ambient 
pressure, etc.), and the abort modes or contingencies available at that point in the 
mission profile. Thus a value of Pd of 0.05 is not simply ten times worse than a 
value of 0.005; multiplication with (1 - PMS) amounts to an adjustment based on the 
likelihood of failure. 

Although typically the riskiest part of any space mission, the ascent phase is only 
part of the total exposure to hazards for the crew. Should the safety attribute 
quantify the risks during the rest of the mission? To test the premise that ascent 
alone would represent all significant losses to be incurred for any given system, a 
typical flight phase representation for on-orbit operations and descent and landing 
operations was evaluated. The values of Pd during on-orbit operations are well 
below the level of descent and landing, which are typically an order of magnitude 
below the ascent phase. As the on-orbit operations values are so low, and given the 
high degree of variability that might be encountered from mission to mission, it was 
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Element: HR Titan IV/PLS 
Flight Phase: Stage 1 (Core) Ignition 


Emergency 

Probable Cause 

%of 

Failures 

P 

Survivable 

P 

Abort 

Explosion 

Propellant leak, turbopump 
failure 

19 

0.5 

0.8 

Fire 

Propellant leak, APU, fuel 
cells 

15 

0.3 

0.7 

Loss of Control 

Actuator failure, GN&C 
failure 

20 

0.07 

0.6 

Damaged 

Vehicle 

Shock interactions, transient 
loads 

5 

0.5 

0.8 

Benign Failure 

Software, failure of non-critical 
system 

40 

0.9 

0.97 

Hazardous 

Environment 

ECLSS failure, leak in pressure 
shell 

1 

0.97 

0.9 


100 

PD = 0.1311 


Figure 3.2.3.2-1- Sample safety worksheet. 


decided not to include on-orbit operations or descent and landing in the calculation 
of the safety attribute at this level of study. 


3.2.3.3 System Results 

Although the most significant safety comparisons are made at the architectural level 
(multiple systems with variable flight rates), it is informative to examine the 
relative loss rates of different human systems used in this study. Figure 3.2.3.3-1 
depicts the average number of flights between crew loss events for the thirteen 
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Average Flights Between Failures 


■ Crew Low Events 
- Failure Event* 



Figure 3.2.3.3-1.- Relative loss rates for human systems. 


human systems. The table directly below points out some major features related to 
safety that help in understanding the relative loss rates. 

3.2.3.4 Utility Curves 

Development of the utility curve for the safety attribute involved two areas of 
significant discussion within the NIT: the nature of human loss which was to be 
measured and the shape of the curve itself. Discussing human losses, especially as it 
relates to the highly visible astronaut corps, is an emotional argument. To arrive at 
the utility curve, some basic questions that the NTT debated at length were: 

a. What would the nation be more concerned with, 3 failures of a human system 
in the next 25 years, or a loss of 12 people in the next 25 years? 
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b. Is the loss of one vehicle carrying six people the same as the loss of three 
vehicles, each carrying two persons? 

c. Is the rate or timing of loss events important? For example, do two loss events 
(before the year 2020) 2 years apart have the same score as two loss events, 10 
years apart? Can this effect be responsibly modeled within this study? 

d. Should loss calculations be rounded off? While only integers are valid to count 
actual losses, can rounding up lead to erroneous conclusions? For example, is a 
calculated value of 2.006 losses equal to two or three loss events? 

Within the limitations of this study, the consensus of the group was to base the 
utility curve on the number of total loss events (non-integer) over the duration of 
the architecture. 

The shape of the utility curve was debated at the NIT forum and the choices 
narrowed to two general types of functions. One school of thought within the NIT 
was that each loss event represents a serious blow to the credibility of the human 
space program and the score would geometrically decrease by one-half for each 
additional loss (refer to curve (a) on Figure 3.2.3.4-1). Another group within the NIT 
felt that a trend similar to curve (b) of Figure 3.2.3.4-1 would reflect the customers 
limited tolerance for system failures. Public opinion may or may not be driven by 
each failure, but the logic behind curve (b) was that the customer, the decision 
maker, had the perspective that: past investment in the system(s) was substantial, 
failures do happen despite the best efforts and are not necessarily symptomatic of a 
generic flaw in the transportation approach, and the costs (fiscal and political) of 
moving to a new system may be unacceptably high. Ultimately, curve (c) was 
selected as an average representation. 

The final version of the utility curve is depicted in Figure 3.2.3.4-1 as curve (c). The 
range of values for the losses, where the utility score decreases from one to zero, is 
determined by the minimum to maximum range of losses across all architectures 

within a given "If". 
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Figure 3.2.3.4-1.- Candidate utility < 
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3.2.4 Probability of Mission Success 


3.2.4.1 Definition 

The PMS is the number of successful missions, including transportation elements, 
but not payload, divided by the total number of missions, including reflights, to 
work off the effects of failure. Successful missions are defined as accomplishing the 
jobs described in the mission model, not necessarily returning the reusable 
hardware or flight crew safely. 


3.2A.2 Measurements 

Calculating the PMS begins with describing the phases of flight for each system and 
constructing a system success tree. Equations are then defined to determine the 
probability of success of each flight phase. The input values for each variable in the 
equations are determined for each system and the final PMS is calculated. The 
architecture value is obtained by flight rate averaging the value for each system and 
then combining all of the system scores in that architecture. 


System Success Trees 

The foundation for quantifying PMS is the system success tree. The tree developed 
for the Space Shuttle (Figure 3.2.4.2) is used here to explain its development. A full 
complement of system success trees can be found in the section B.l.9.2 of the 
Technical Appendix. 

Initially, the mission profile was divided into three parts: ascent, orbit, and descent 
Each part was then subdivided into phases based on distinct flight events. These 
phases represent distinct launch vehicle reliability and/ or safety changes. For the 
Space Shuttle, there are four different propulsive modes during ascent: SSME 
ignition and thrust buildup (Phase 1), SRB ignition through burnout (Phase 2), 
SSME operation from SRB jettison through main engine cut-off (MECO) (Phase 4), 
and orbit circularization (Phase 8). Two staging events; SRB and ET jettison, occur 
during ascent. SRB jettison (Phase 3) separates Phases 2 and 4. The ET is jettisoned 
(Phase 3) shortly after MECO. In addition, there is a coast period (Phase 7) between 
ET jettison and orbit circularization. 

Orbit success trees were developed for six distinct mission types: space station crew 
exchange (internal, or pressurized), servicing, external servicing, sortie science, 
deployment, and retrieval. Twelve different activities have been identified for on- 
orbit operations. A job can employ any number of operations, but they all begin 
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SHUTTLE ASCENT SUCCESS TREE 



PHASE DESCRIPTION COMMENTS 

1 SSME IGNITION IGNITION AND THRUST BUILDUP 

2 SRB IGNITION IGNITION AND LIFTOFF 

3 SSME/SRB BURN TIME PARALLEL BURN TIME TO SRB TAILOFF 

4 SRB SEPARATION 

5 SSME BURN TIME THROUGH MECO 

6 ET JETTISON 

7 COAST 

8 OMS CIRCULARIZATION INCLUDES IGNITION, BURN & CUTOFF. 

Figure 3.2A.2 - Space Shuttle ascent success tree. 


and end with an orbit change. Each system flight can perform multiple jobs and 
more than one of each job. These on-orbit trees are generic and apply to any system. 

Descent trees are also generic. They are comprised of six different operations, 
beginning with the deorbit bum. Vehicle alignment for entry (Phase 2) is crucial for 
successful return. Phase 3 extends from entry interface to the point where 
aerodynamic surfaces can be used. Terminal area energy management defines 
Phase 4. The use of propulsive hardware during the return phase is covered by 
Phase 5 (this applies to rocket engines or air-breathing engines). Landing and roll 
out are included in Phase 6, which begins just prior to landing gear deployment. 
On-orbit and descent phases were common across all systems and, therefore, did not 
contribute to mission success comparisons between systems. For this reason the 
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ascent phase was the only part of the mission trees that was modeled for reliability 
analysis. 

Modeling System Reliability 

A review of space launch attempts shows that failures can be grouped into three 
categories: engine failures, propulsion system failures (tanks, lines, etc.) and other 
failures (avionics, electronics, etc.). The equations used in this study account for the 
number of engines, stages, and their associated reliabilities. If a system has three 
engines on one stage, the reliability is cubed. If a particular event (e.g., SSME bum) 
occurs across several phases, the reliability for that functioning hardware is raised to 
a power of one over the number of phases in which it operates. A cumulative 
reliability for a candidate system is the product of the reliability of each phase. 

As an example, the following equations were developed for the first five phases of 
the Space Shuttle ascent. 

RSI = Stage 1 Propulsion Hardware 
AR = Avionics Reliability 
RL = Liquid Engine Reliability 
RSS = Segmented Solids Reliability 

Phase 1 - SSME ignition and thrust buildup 

Rpl = RSI 1 / 4 * AR 1 / 8 * (RL 3 ) 1 / 4 

Phase 2 - SRB ignition 

R p2 = RSI 1 / 4 * AR 1 / 8 * (RL 3 ) 1 / 4 * (RSS2)V2 

Phase 3 - SSME and SRB burn 

Rp3 = RSI 1 / 4 * AR 1 / 8 * (RL 3 ) 1 / 4 * (RSS2)!/2 

Phase 4 - SRB Separation 
Rp4 = AR 1 / 8 * 0.9999 
Phase 5 - SSME burn to cut-off 

R p 5 = RSI 1 / 4 * AR 1 / 8 * (RL 3 ) 1 / 4 

A complete list of system equations can be found in the Volume 2 Technical 
Appendices, section B. 1.9.3. 
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Deriving System Engine. Stage, and Avionics Reliabilities 


Two methods of calculating reliability values for launch vehicle hardware were 
investigated. They were calculating mean-time-between-failure (MTBF) values and 
calculating probabilities of success for hardware groups. 

The first method was an attempt to develop a MTBF value for each hardware 
component to take into account the effect of operating time on hardware 
reliabilities. This method proved difficult for two reasons. The first reason was 
that a credible method of estimating MTBF's for future launch systems could not be 
found. The second reason this method was not used was that using MTBF data 
would have caused an increase in the number of failures with an increased bum 
time. Analysis of launch histories indicates that nearly as many failures are cycle- 
dependant and occur early in a launch as are time-dependant and occur after 
extended flight time. The spread of launch vehicle failures over time has been 
confirmed by other reliability studies 2 . 

The second method, deriving a probability of success for hardware groups, was the 
method that was chosen for this study. A database of Delta, Atlas, Titan, Saturn, and 
Space Shuttle flight history was used to establish a reference reliability of the three 
types of hardware system - engines, propulsion systems, avionics. The history of 
each hardware type was researched to determine the number of flights the hardware 
type was flown and the number of failures that have occurred. Flights were 
accumulated based on the number of flights an item was flown (e.g., one Space 
Shuttle launch is five flights of a liquid propulsion engine, three SSME’s, and two 
Orbital Maneuvering Systems (OMS)). The probability of success for a hardware type 
was calculated using the following formula: 

Reliability (component) = 1 - ( # FAILURES / # FLIGHTS) 


Because the number of engines is not equal to the number of stage propulsion 
hardware systems, the failures for this hardware were broken into two groups. 
Failures occurring in pressurization systems, tanks, lines, and valves were used in 
the calculation for the stage propulsion hardware reliability. Failures occurring in 
the engine (i.e., combustion chamber, nozzle cooling system, and gas generators) 
were used in the engine-reliability calculation. The following are some examples of 
failures that were attributed to stage propulsion hardware: 


DATE VEHICLE 

8/7/66 ATLAS 

8/9/84 ATLAS 

9/1/64 TITAN 

10/21/71 DELTA 


CAUSE 

Centaur propellant leak 
LOX leak created lateral thrust 
Transtage lost helium pressure 
Oxidizer vent valve lost 
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For those systems which could lose an engine during ascent and still achieve the 
proper orbit, the following equation was used to account for the increase in PMS: 

Rn engines with engine out = RL n + (n * RL n_ l * (1- RL)) 

The more engines a launch system relies on, the lower its reliability. The SSTO 
system has the most engines of any system in the HTS study. Because it has engine- 
out capability, only 11 of the 12 engines need to work. Its statistical probability of 
success, therefore, is enhanced greatly by engine-out capability. 

A sensitivity study was done to determine the need for including a parameter to 
measure the effect of an engine failure causing catastrophic damage to the other 
engines on the vehicle (engine correlation factors (CF)). A CF could expose the 
down side to engine out, since the additional engines could have an increased 
chance of failing catastrophically and damaging other engines. The SSTO was used 
as the test for this trade as it has the most engines and has engine-out capability. 
Using a CF of 0.2, meaning that 20 percent of engine failures propagate beyond the 
initial failed engine and, therefore, cause mission loss, the difference in PMS was 
decreased by only 0.005. With the SSTO flying 330 flights, this increased the number 
of mission failures by only 1.65. It was decided that the effect was not large enough 
to add value to the study results. 


3.2.4.3 System Results 

The final calculated PMS values for the systems used in this study are presented in 
Table 3.2.4.3-1. It is important to note that the purpose of this analysis was to 
provide a way of comparing relative reliabilities of different launch systems and not 
to develop a point reliability value. In addition, since the avionics reliability value 
was a single multiplier used on all systems and did not contribute any comparative 
information, it was eliminated from the final score. The effect of eliminating the 
avionics reliability was to increase the predicted system reliabilities by 1.6 percent. 

Also, by using a single value based on all launch history since 1964 for a hardware 
type (such as liquid engines), some existing individual launch vehicles have lower 
combined reliabilities than their present launch history indicates. An example of 
this is the Titan IV. If a PMS was calculated for this system according to its recent 
flight history it would be 0.958. Using the study model yields a PMS for the Titan IV 
of 0.9307. This bias, however, is applied across all systems and, therefore, does not 
detract from the validity of its intended purpose as a tool for relative comparison. 

Figure 3.2.4.3-2 depicts the results of the study along with indications of the major 
features that effect the PMS values: number and type of engines, engine-out 
capability, and number of stages. 
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3.2.4.4 Utility Curves 


The utility curve for PMS is based on assigning a value of 1.0 to the architecture 
with the highest PMS and a value of 0.0 to the architecture with the lowest PMS for 
a given "If" scenario. By graphing the results with a straight line connecting these 
two points, some value between 1.0 and 0.0 can be assigned to each vehicle analyzed. 
It is important to note that the values of 1.0 and 0.0 are used only as starting and 
ending points and do not indicate any judgment as to the value of a particular 
vehicle configuration. These numbers are used only as a starting point for 
comparison purposes. 


TABLE 3.2.4.3-1.- PMS RESULTS 


SYSTEM 

PMS 

STAGES 

ENGINES 

ENGINE 

OUT? 






AMSC 

.9577 

2 

5 

N 

ATLAS HAS 

.9326 

3 

7L,4MS 

N 

ATLAS EV 

.9369 

3 

5L,4MS 

N 

BETA II 

.9652 

2 

3 

Y 

DELTA 

.9319 

3 

3L,10MS 

N 

MLS-X (CTV) 

.9455 

3 

10 

Y 

MLS-X (RPC) 

.9544 

3 

12 

Y 

MLS-X (non SSF) 

.9842 

1 

6 

Y 

MLS-HL (NUS) 

.9691 

2 

9 

Y 

MLS-HL (CTV) 

.9455 

3 

11 

Y 

MLS-HL 

(RPC/LRV, 

CRV,CLV) 

.9543 

3 

12 

Y 

NLS-20 (AUS) 

.9435 

3 

5 

N 

NLS-50 (CTV) 

.9455 

rs 

10 

rY 

NLS-50 (RPC) 

.9544 

3 

12 

Y 

NLS-50 (NUS) 

.9842 

1 

6 

Y 

NLS-50 (AUS) 

.9455 

~3 

10 

Y 
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TABLE 3.2.4.3-1.- PMS RESULTS (CONCLUDED) 


NLS-HL (CTV) 

ES&IsHHHH 

3 

8L,2SS 

Y 

NLS-HL (CRV) 

.9308 

3 

8L,2SS 

Y 

NLS-HL (AUS) 

.9308 

3 

8L,2SS 

Y 

SSTO 

.9691 

2 

14 

Y 

E3?S§E33S3B1 

.9431 

2 

5L,2SS 

N 

Shuttle evolution 

.9290 

4 

13 

Y 

RCV 

.9290 

4 

13 

Y 

TITAN II 

.9626 

2 

3 

N 

MR TITAN II 
(RUPC) 

.9323 

3 

7L,10MS 

Y 

TITAN III 

.9307 

3 


N 

TITANev 

.9519 

2 

5L,2SS 

Y 

TITANev/CENT 

.9166 

4 

7L,2SS 

Y 

TITAN IV (NUS) 

.9307 

3 

4L,2SS 

N 


L - Liquid Engines Y - Yes 

SS - Segmented Solids N - No 

MS - Monolithic Solids 



Figure 3. 2.4. 3-2 - System features and PMS. 
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3.2.5 Architecture Cost Risk (ACR) 


This section contains the definitions of the ACR attribute, its measurements, and a 
discussion of the process by which the architecture cost risk estimates were 
generated. 


3.2.5.1 Definition 

After much deliberation, described in subsequent paragraphs, the NIT defined ACR 
as the risk, or expression of uncertainty, in developing, producing, and operating all 
systems in an architecture at their stated costs, based upon their present level of 
definition. Although the expressions of risk approximate the relative cost risk 
between architectures, the reader is cautioned against using the results obtained 
from this methodology to predict uncertainity in absolute dollar amounts of the 
estimates, or to estimate required levels of program reserves. 

3.2.5.1.1 Architecture Cost Risk modeling .- The NIT reviewed and discussed 
several methods for evaluating the risk attribute of space transportation system 
candidates in the selected HTS architectures. These were used to form a consensus 
on the most appropriate method of measuring the cumulative risk of any given 
architecture. It was decided that the NIT should pick a modeling technique which 
could handle all of the primary risk elements associated with human space 
transportation programs. The selected uncertainty model should provide a 
"standardized" framework, with common formats and scaling levels for all the 
architecture elements (space system projects) to be analyzed. 

The traditional program risk areas of Schedule, Management, Technical, and Cost 
could be addressed in a cost risk model. The political and social risk areas were not 
chosen to be addressed in the risk evaluations, since their associated-probability- 
level selections would be hard to quantify and defend. Several cost risk modeling 
methods and tools were considered. The two principal methods considered are 
described below. 

The ©RISK Cost Modeling System 

The @RISK modeling application software is. a commercially-available, analytical, 
assessment product for risk evaluation. The model is basically a mathematical 
probability and statistical analysis tool. It can be used for evaluating the risk ranges 
of variable cost estimates or reliability estimates. 

The ©RISK model applies user-selected distribution curves to the program 
elements being analyzed. The curve selections can be varied from beta (skewed, 
unimodal) distributions, standard distributions, histogram distributions (square, 
"step" curves), or even to the application of triangular distributions. The tool is 
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available to all potential customers with a personal computer and enough computer 
memory capability to operate the program. 

The ©RISK modeling tool was not selected because of the required setup and 
background detail to properly document the risk evaluation inputs. The model was 
viewed by many members of the NIT as more appropriate for an "in-depth" analysis 
of the candidate architecture elements. This model could be used after lower detail 
description levels are obtained for the system hardware projects to be analyzed (with 
better test requirements and hardware characteristics definitions). 

The Boeing Ranger Cost Uncertainty Model 

The Ranger Cost Uncertainty Model was developed for internal cost risk 
evaluations by Boeing Aerospace Company (now called Boeing Defense and Space 
Group) in 1985. This proprietary model was developed for acquisition cost estimate 
evaluation. Acquisition estimates include cost elements for the development and 
production phases of an aerospace program. Ranger is used at Boeing to evaluate 
risk with parametrically-derived or preliminary planning cost estimates (where a 
minimal amount of program definition data is available to the analyst). 

The Ranger model utilizes inputs of the program estimate by subsystem and task 
elements. The program item estimates must exclude program contingency and 
management reserve factors. The Ranger high value estimate outputs can be 
compared later to the user-selected management reserve or contingency factors to 
judge whether the factor levels are too high, too low, or just about right to cover the 
modeled uncertainty environment. The model also uses a standardized uncertainty 
factor selection scale, shown in Figure 3.2.5.1.1-1. 

The preferred method for using the Ranger factors scale is to gather separate risk 
factor inputs in the four risk categories for each estimated line item from design, 
system engineering, management, manufacturing, and estimating personnel. A 
consensus (using "Delphi" methods) interview is conducted with each functional 
design or management area representative by an experienced cost analyst. A 
successful interview requires the following information: a credible program master 
planning schedule; the reference estimate inputs; the factor selection scale; and 
system hardware or task descriptions at the subsystem level for each phase 
evaluated. 

System operation and support cost estimates are not addressed because the Ranger 
model was not developed initially to evaluate "ownership" cost estimates. The 
Boeing Ranger Uncertainty Model uses an "expert opinion" lookup table to set 
range limits in the four acquisition risk areas. These limits were established by 
Boeing senior managers and engineers in interviews concerning past space and 
missile program development and production cost variance environments. 


3.2-40 


Rev. E 



SCHEDULE DRIVERS 

• Length 


Appropriate 

Contingency 


Reasonable 


Too Long 
or Short 


Too Short 


► Synch with 

Interfaces 

► Dev/Prod 

Overlap 


Time to Test Interface 


No Overlap 


Serial Loading 
Minimal Overlap 


Parallel Load Out of Sync 
Some Overlap Much 0\ crlap 


PROGRAM DEFINITION 

• Requirements 

• Organization 

• Funding 


• Communication 


- Management 


Minimal Ambiguity Ambiguous 


Clear Command 
and Well Staffed 


Adequate with Reserves 


Well Staffed 


Inadequate Staffing Conflict 


Adequate and Steady Irregular Poor 


Effective Conprehensive Comprehensive Incomplete Dysfunctional 


Experienced Effective 


Experienced Inexperienced 


Disruptive 


TECHNICAL CHALLENGE 

• State of Technology 
■ Experience 

• Technical Approach 

• State of Specs 


State of the Art 


Some 

Advance 


Much New 

Advance Tech 


Same Product 


Standard 


Similar Product 


New Line 
Same Tech 


New Tech 


Available 


New Processes 


Some New 


Complete 

Need Inovation New Approach 


All New 


No Standard 


ESTIMATING APPROACH 


- Accuracy of Tools 


- Estimator Experience 
■ Support from Program 


► Reviews 


Extension of 

Actuals Firm Quotes Good Parametrics 


Familiar with Product 


Good Inputs 


Regular 


Educated Guesses 
Minimal 


Familiar with Minimal 

Similar Product No Familiarity Experience 

Uncertain Clear Sloppy Inputs 

Inputs Minimal Staffing 
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3.2.5. 1.2 Ranger evaluation results .- Preliminary evaluations were accomplished 

for most of the new system hardware elements in the 18 architectures. The 
elements which were not evaluated either had only one summary cost estimate 
number (with no subsystem detail information submitted), lacked a we - 
documented program master schedule for reference, or had major information 
voids present in all process inputs. The Ranger method was eventually not 
considered useful in the initial HTS architecture evaluation process for the 
following reasons: 


Some system estimates did not contain sufficient definition to run the Ranger 
model at the proper technology application risk evaluation level (the Ranger- 
desired program cost estimate breakout inputs of structure, propulsion, avionics, 
flight controls, software, and crew systems of personnel vehicles was not 
consistent for all systems). 


• The risk factor selection inputs for some system production theoretical first unit 
(TFU) estimates were inconsistent due to interviewee differences in levels o 
manufacturing experience. Manufacturing and engineering personnel were not 
always available for the interviews. Experience in using the Ranger model has 
shown that lack of a mix of disciplines in a production estimate interview seems 
to unfairly bias the outputs for both low ("marketeer" optimism) and high 
(fabrication and delivery failures pessimism) values. 


In some cases, a complete program master schedule with hardware and task 
category development breakouts for each estimated line item was not available 
for reference in the interview process. Many preliminary system master 
schedules had no first unit production flows shown for the interviewees to use 
as reference material for selection of uncertainty factors. 


The Ranger outputs showed little "high" to "reference estimate" ratio sensitivity. 
This resulted in the clustering of upper stage and scattering of booster risk 
values. The clustering of vehicle risk factor results did not provide the desired 
or expected differentiation to break ties between competing systems. 


• Ranger is not applicable for addressing operations and support cost estimates, so 
the total life cycle cost uncertainty could not be evaluated. 


• The Ranger model is considered a company proprietary tool. 

3 2 5.1.3 NTT consensus methodology .- Since each of the risk models identified 
were either deficient or too detailed for the level of information available the NIT 
set out to determine its own relative measure of risk using the most sigm ican „ 
contributing factors to architecture cost risk. Using a "nominal group technique , 
the architecture cost risk was determined to be a function of three primari y 
parameters, or subattributes: 
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• Technical Challenge (TO.- The TC represents the degree to which a 
transportation system's technology deviates from current technology. The 
technologies of the candidate systems ranged from being essentially off-the-shelf 
to entirely new technologies. The TC of transportation systems can be 
determined - independent of how a system is used in any architecture. 

• Program Immaturity (PI).- The PI represents the current actual state of definition 
of a system, based primarily upon a current drawing count. The PI of 
transportation systems can be determined - independent ot how a system is used 
in any architecture. 

• Number of New Systems (NS).- The NS is simply the count of the number of 
new systems in the candidate architecture, with credit acknowledged for families 
of systems where vehicles which use significant common hardware with other 
vehicles in that architecture are recognized as not being entirely new 
developments. The NS is a direct architecture-level measurement. 

Consensus weightings for the contribution of each subattribute to the overall 

architecture cost risk was determined by the NIT to be as follows: 

Technical Challenge 45% 

Program Immaturity 30% 

Number of new Systems 25% 


3.2.5.2 Measurement of the Attribute 

The following section describes the methodology used to develop the relative 
architecture cost risk. 

3.2.5.2.1 Technical challenge .- The relative technical challenge of each system 
comprising the architectures was assessed by the HTS team. This was accomplished 
by determining the technical challenge of each of the phases in the life cycle of each 
system: the development, or non-recurring phase (which includes DDT&E, non- 
recurring production, facilities, and pre-planned product improvement); the 
production phase; and operations phase, and then cost-weighting the TC of each 
phase by the cost of that phase. The relative assessment of TC for each phase was 
made by having each NIT member assess an integer value from 1 (least technical 
challenge) to 10 (most technical challenge) to each phase of each system. A 
consensus value was then selected to represent the assessment of the NIT. Table 
3.2.5-1 provides the consensus results of this phase-level assessment, along with the 
range of inputs received during the process. 
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TABLE 3 2.5-1.- PHASE-LEVEL TECHNICAL CHALLENGE FOR 
TRANSPORTATION SYSTEMS 


System 

Non-Rec 

TC 

R 

Prod 

TC 

R 

Ops 

TC 

R 

AMLS 

7 

5-7 

6 

4-7 

6 

4-7 

AMSC 

6 

3-7 

4 

3-7 

6 

5-9 

ACRV 

3 

2-4 

2 

1-4 

3 

2-5 

Atlas 

1 

1 

1 

1 

1 j 

1 

Atlas Evolution 

2 

2-3 

1 

1-2 

1 

1-2 

Atlas/Delta/Titan CTF 

4 

2-7 

2 

1-4 

3 1 

1-7 

Beta II 

8 

Will 

7 

5-9 

8 

6-9 

CLV 

5 

2-6 

3 

1-5 

3 

1-5 

CRV 

4 


3 

1-5 

3 

1-5 

CTV 

4 

W&M 

3 

i-5 i 

3 

1-5 

Delta 

1 

1 

1 

1 

1 

1 j 

LRV 

3 

mzm 

3 


2 

1-5 

MLS 

4 

ta 

4 

ESI 

3 

3-4 

HR Titan > 

3 

2-5 

2 

1-2 

3 

2-4 

NASP Derived Vehicle 

10 

10 

10 

10 

9 1 

9-10 

NLS-1 

4 

3-6 

4 

3-5 

3 

3-4 

NLS-2 

4 

3-6 

4 

3-5 

3 

3-4 

NLS-3 

4 

3-6 

4 

3-5 

3 

3-4 

RCV 

3 

2-4 

2 

1-3 

3 

2-3 

RPC 

5 

2-5 

3 

1-5 

3 

3-7 

RUPC 

8 

5-9 

6 

5-7 

3 

3-8 

Space Shuttle 

1 

1 

1 

1 

1 

1 

Shuttle Evolution 

3 

2-4 

2 

1-2 

3 

2-4 

SSTO (Rocket) 

9 

5-10 

6 

4-10 

9 

6-9 

Titan II 

1 

1 

1 

1 

1 

1 

Titan IV 

1 

1 

1 

1 

1 

1 

Titan IV Evolution 

3 

2-4 

2 

1-4 

2 

1-2 

HR Titan HS 

3 

i -n 1 

2-4 

2 

1-4 

2 

} — Ranap 

1-2 


NonRec = Non Recurring; Prod = Production; Ops = Operations; R - Range 


3 25 22 Program immaturity - The relative program immaturity of each system 
was assessed by the HTS team. The relative assessment was made by having each 
NIT member assess an integer value from 1 (least program immaturity) to 10 (most 
program immaturity) based upon an estimate of the percentage completion of 
applicable drawings. The HTS program immaturity scale, with the explanation of 
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the program immaturity levels, is provided in Table 3.2.5-2, and is based upon a 
subset of the NASA-JSC Advanced Missions Cost Model. 


TABLE 3.2.5-2.- HTS PROGRAM IMMATURITY SCALE 


Rank 

Explanation 

1 

Virtually 100 percent of the drawings exist and need not be 
renumbered; the continuation of an existing product. 

2 

Predominant number of drawings exist; drawings may have been 
renumbered. 

3 

Majority of drawings exist; minor resizing of hardware is possible. 

4 

Roughly half of the drawings exist; significant resizing of hardware 
is possible. 

5 

Only a minority of drawings exist; however, existing drawings are 
based on a familiar product line. 

6 

Drawings are essentially new; however, a design point-of-departure 
is known to exist. 

7 

Drawings are new, the mission of the design are, in part, unfamiliar. 

8 

Drawings are new, either mission or design concept is unfamiliar. 

9 

Drawings are new, both mission and design concepts are unfamiliar. 

10 

Drawings are new, and the design concepts transcend the state-of- 
the-art. 


A consensus value was then selected to represent the assessment of the NIT. 

Table 3.2.5-3 provides the consensus results of this assessment, along with the range 
of inputs received during the process. 

3.2.5.2.3 Number of New Systems .- The number of new systems comprising the 
architectures was assessed by the HTS team. The relative assessment was made by a 
count of the number of new systems in each architecture. Families of systems in an 
architecture were evaluated for the number of distinctly new systems represented by 
that family; in other words, a family was given credit for commonality. A consen- 
sus value was then selected to represent the assessment of the NIT. Table 3.2.5-4 
provides the consensus results of this assessment, along with the range of inputs 
received during the process. 

3.2.5.2.4 Total Architect ure Cost Risk .- To make the relative linear assessment of 
TC and PI more closely approximate the impact of TC and PI on the cost risk 
experienced in real programs, an algorithm was developed to spread the consensus 
input TC values 


3.2-45 


Rev. E 











TABLE 3.2.5-3- SYSTEM LEVEL PROGRAM IMMATURITY FOR 
TRANSPORTATION SYSTEMS 


System 

Program 

Immaturity 

Range 

Element List 



AMLS 

8 

6-9 

AMSC 

7 

6-9 

ACRV 

5 

4-7 

Atlas 

1 

1 

Atlas Evolution 

3 

2-4 

Atlas/Delta/Titan CTF 

6 

4-8 

Beta II 

10 

9-10 

CLV 

7 

6-8 

H. 

CRV 

7 

6-8 

CTV 

6 

5-8 

Delta 

1 

1 

LRV 

7 

6-8 

MLS-HL, MLS-X 

6 

5-7 

HR Titan 

4 

3-6 

NASP Derived Vehicle 

10 

10 

NLS-1 

6 

4-7 

NLS - 2 1 

6 

4-7 

NLS-3 

6 

4-7 

RCV 

4 

3-4 

RPC 

6 

4-7 

RUPC 

7 

6-8 

Space Shuttle 

1 

1 

Shuttle Evolution 

4 

3-4 

SSTO (Rocket) 

8 

7-10 

Titan II 

1 

1 

Titan IV 

1 

1 

Titan IV Evolution 

4 

3-4 

HR Titan IIS 

3 

2-4 
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TABLE 3.2.5-3 - SYSTEM LEVEL PROGRAM IMMATURITY FOR 
TRANSPORTATION SYSTEMS (CONCLUDED) 


System 

Program 

Immaturity 

Range 

System List 



Atlas /Delta CTF 

6 

- 

CLV/MLS-HL 

7 

- 

CRV/MLS 

7 

- 

CTV/NLS-1 

6 

- 

LRV/NLS-1 

7 

- 

RPC/MLS-X 

6 

- 

RPC/HR Titan IV 

6 

- 

RPC/NLS-2 

6 

- 

RPC / LRV / MLS-HL 

7 

- 

Titan IIS/RUPC 

7 

- 


TABLE 3.2.5-4.- NUMBER OF NEW SYSTEMS 


System 

Number of 
New Systems 

Range 

ACRV 

1.0 

0.8-1 .0 

AM SC 

1.0 

1.0-1 .2 

Atlas Evolution 

0.2 

0.1-0.3 

Atlas/Delta CTF 

1.0 

0.7-1. 0 

Beta II 

1.7 

1. 0-2.0 

CRV 

1.0 

1.0 

CRV 

1.0 

1.0 

CTV 

1.0 

1.0 

LRV 

1.0 

1.0 

MLS-X + RPC, MLS-HL 

2.8 

2.2-3.0 

MLS-X and MLS-HL/CLV 

2.7 ; 

2.0-3.0 

MLS-X, MLS-HL + CLV 

2.7 

2.0-3.0 

HR Titan II + RUPC 

1.4 

1.2-1. 5 

HR Titan IV + RPC 

1.4 

1.2-1. 7 

NLS-1,2 (w/AUS) 

1.6 

1. 2-2.5 

NLS-1,2 + RPC 

2.5 

22 - 2.6 

NLS-1,2,3 (w/AUS), 

2.5 

22 - 4.0 
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TABLE 3.2.5-4.- NUMBER OF NEW SYSTEMS (CONCLUDED) 


System 

Number of 
New Systems 

Range 

NLS-1,2 + RPC 

2.5 

2.2-2.6 

NLS-1,2,3 (w/AUS), 

2.5 

2.2-4.0 

NLS-1,2,3 + RPC 

3.4 

3.3-3.5 

SSTO 

1.0 

1.0 

Shuttle Evolution + RCV 

HHHKEflHBH 

05-1.1 

Titan CTF 

1.0 

0.9-1. 0 

Titan Evolution 

0.5 

0.1-0.8 


prior to developing the final relative architecture cost risk. That algorithm was then 
applied to spread the TC for each phase of each system and the PI for each system. 
The algorithm developed for the spread value of TC and PI was 

sv = (1.6681) fa" 1 ) 

where n is the linear number assigned to TC or PI. 


The TC or PI spread function is plotted in Figure 3. 2.5-1. 



Figure 3.2.5-1- TC and PI spread function. 


This function more closely approximates the experience reflected in more 
sophisticated cost uncertainty models, which show that 'beating the midrange or 
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nominal estimate for TC and PI does not appreciably mitigate the risk, while 
underestimating the TC and PI results in a substantial cost risk. 

The TC for each system was then derived by cost-weighting the exponentially spread 
values of TC for each phase by the total cost of that phase. The total architecture TC 
is the sum of the cost-weighted TC for each system in that architecture. The PI for 
the entire architecture was derived by weighting the exponentially spread values of 
PI for each system by the flight rate of that system in that architecture to account for 
the impact of the relative usage rate of the individual systems. The NS for the 
entire architecture was derived by adding the number of new systems in that 
architecture using the values from Table 3.2.5-4. These final TC, PI and NS values 
were then used as input to the utility functions in the HTS AET to aid in a relative 
evaluation of the architectures. 
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3.2.6 Launch Schedule Confidence (LSC) 


3.2.6.1 Definition 

• Launch Schedule Confidence provides an indication of an architecture's ability 
to meet its launch schedules. It is determined by the measurement of three 
subattributes- schedule compression, schedule margin, and percentage of flights 
with delays. 

• Schedule compression provides insight into the ability of a system’s ground 
processing flow to absorb unscheduled or unplanned activities while still 
remaining on schedule. 

• Schedule margin compares the utilization rate of a system's ground processing 
facilities associated with meeting the required annual flight rate relative to the 
maximum annual throughput capability of those facilities. 

• The percentage of flights with delays is an estimate of a system's likelihood to 
have a launch delay based on unscheduled maintenance items occurring at 
critical times in the flow. 


3.2.6.2 Measurement of Attribute 

This attribute has three parts to its measurement, as described above. Each will be 
measured separately and then combined. The architecture value is obtained from a 
flight-rate-weighted average of the individual system's values. 

The first two subattributes utilize data associated with the ground processing flow 
for each element or system. To facilitate these first two measurements, summary 
level, ground-processing-flow schematics were prepared for each element or system. 
An example, representing the current Atlas launch vehicle, is shown in Figure 
3.2.6-1. Pertinent information contained in the schematic includes the identification 
of the major components of the system, the unique facilities and their number used 
in the processing flow, and the processing time (in work days) and shift information 
associated with the flow's critical path. Similar schematics for all the elements and 
systems can be found in the Appendix B. 
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ATLAS 



Figure 3. 2.6-1- Atlas processing. 


Schedule compression .- This is a measure of a system's ability to make up schedule 
slips by extending shifts and adding work on weekends to the processing flow. 

Those parts of the ground operations flow that are in the critical path are boosted to 
7-day-per week operation along with increasing the shift size by 50 percent. For 
example, if the nominal processing flow has one 8-hour shift, the compressed flow 
would have 1.5 shifts, or 12 hours. In cases where two 8-hour shift operation is the 
norm, the compressed flow would have two 12-hour shifts, or round-the-clock 
operations. This assumes that new crews are not hired, but that existing crews work 
overtime. 

The compressed flow is expressed in consecutive days. This is compared to the total 
number of calendar days required in the nominal flow. In the sample flow shown 
above, the total calendar days in the nominal flow along the critical path is 66 days. 
The compressed flow time is 34 days. For the last five days on the pad, no com- 
pression is possible since the single crew is already working above the 50 percent 
shift time extension. The difference between this compressed flow time and the 
nominal flow time, 32 days (66 - 34), is divided by the nominal processing time 
(66 days) to show how long the compressed time is relative to the normal process 
flow (32/ 66 = 0.485). This number is independent of flight rate and is a constant for a 
given element or system. The schedule compression for an architecture is the total 
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system flight averaged schedule compression for all the systems manifested in that 
architecture. This calculation is performed within the Architecture Evaluation 
Tool. 

Schedule margin .- This is a measure of a system's ability to make up schedule or 
launch slips by using facilities and personnel that are not working at full capacity 
since, for any particular year, there are fewer flights than those for which the 
system's ground facilities are designed. This calculation is made using the most 
process-time-limiting facility in the critical path. This is usually the facility 
requiring the most time for throughput, however, this is not the case where there 
are duplicate facilities for portions of the flow. The difference between the required 
flight rate in a given year and the design (maximum) flight rate is converted to a 
number of days. This is divided by the nominal processing time to give a ratio of 
the added time relative to the normal process flow. 

In the above Atlas example, the pads represent the "bottleneck" in the processing 
flow. The total time a pad is tied up in the processing flow is 67 calendar days, 
including 9 calendar days of pad turn-around time. Assuming a flight rate of six per 
year, the pads are in use for 402 (67 x 6) days. With two pads, there are 730 (365 x 2) 
days of available pad time. Therefore, the schedule margin for that year, or any year 
with 6 flights, is 328 (730 - 402) days. The schedule margin for an architecture is the 
sum of the annual flight rate averaged schedule margins for all the systems 
manifested in that architecture. This calculation is also performed within the AET. 

Percentage of flights with delays - This measurement is based on a statistical 
correlation using MTBF values developed for existing launch vehicles, space 
systems, and military aircraft. This measurement predicts the number of delays 
which occur in the final portion of the launch processing, i.e., the time during 
which the vehicle and its systems are powered up just prior to launch. This 
measurement does not, however, attempt to measure the length of the delays. The 
mass, complexity, and mission duration of each system is used to calculate a number 
of unscheduled maintenance action (UMA) items that the system would be expected 
to experience. Judgments, based on Space Shuttle experience and sensitivities of 
airline-type operations to delays, are used to determine how many of those 
unscheduled actions appear during the flight countdown, and how many of those 
actually cause a delay. 

Using the Atlas expendable launch vehicle as an example, and starting with the 
predicted average MTBF for the Atlas avionics during the launch phase of 
23.76 hours, a value for MTBF during the ground checkout was derived. This 
calculation was based on the observation that, on the average, the MTBF during 
ground checkout is eight times greater than during the launch phase. This yields a 
MTBF of 190.08 (23.76 x 8) hours. This ground checkout MTBF was then converted to 
a Mean Time Between Maintenance (MTBM) based on the observation that, on 
average, there are 2.04 unscheduled maintenance actions for every failure. This 
leads to a MTBM value of 93.176 (190.08/2.04) hours. Dividing the Atlas' ground 
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checkout time (35 hours) by this value yields 0.376 (35/93.176) UMA's or 0.1074 
UMA’s per hour. Assuming any UMA occurring in the final five hours before 
launch would cause a launch delay due to insufficient time to repair, predicts 0.0537 
(0.01074 x 5) UMA's or delays per launch attempt. In other words, 5.37 percent of 
scheduled launches will be delayed. Similar calculations were made for the Delta and 
Titan launch vehicles using their respective MTBFs and checkout times. The Titan 
MTBF value, the highest of the three, was used in the calculations for the new 
expendable launch vehicles. It was assumed that new vehicles would be at least as 
good as Titan, so this was considered a threshold value for purposes of comparison. 

The same basic procedure was used for calculating delays for the reusable vehicles. It 
is reasonable to further assume that refurbished, reusable vehicles arrive at the pad 
with undiscovered UMA’s and failures resulting from previous flights. These 
previously undiscovered UMA's and failures are detected during the prelaunch 
checkout and are added to the UMA's and failures expected to occur during the 
checkout. From contemporary military aircraft experience (F-16, F-15, FB-111, B-1B, 
C-5, B-52, and C-141) on the average, about 8 percent of all unscheduled maintenance 
needs are discovered just prior to flight (during preflight inspection and during 
engine and system checks). Twenty-eight percent of those UMA’s discovered result 
in flight delay or ground abort. The situation is not quite the same for launch 
vehicles since some systems (e.g., SRB's and other thrust-related equipment) cannot 
be completely tested prior to liftoff. As a result, only about 40 percent of any existing 
UMA’s and failures can be discovered during prelaunch testing (prior to engine 
ignition) on the pad. The remaining UMA’s and failures become apparent following 
liquid engine ignition, but prior to liftoff. These clearly result in launch delay. 
"Percent of flights delayed" values, along with the governing input values and 
assumptions, and intermediate calculated values are given in Table 3.2.6-1 for all the 
element or systems in this study. The element and system values are rolled up into 
architecture "percent of flights delayed" scores within the AET by flight-weighting 
the individual scores. 


3.2.6.3 System Results 

Launch Schedule Confidence results for the systems in all architectures are not 
presented here, as they are flight-rate (of "If" scenario) dependent. Architecture 
values can be found in the Appendix. 


3.2.6.4 Utility Curves 

Utility scores, between zero and one for each subattribute, were obtained assuming a 
linear distribution of the rolled up architecture scores for each subattribute. Within 
an "If scenario, the architecture with the best score received a one, the worst a zero. 
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The final architecture score for LSC was obtained by combining the equally weighted 
utility scores for the three subattributes, essentially averaging the three scores, to 
obtain a single score between zero and one. Since it was unlikely that a single 
architecture would be the lowest or highest in all three subattributes for a given If , 
the range of combined scores would most likely be greater than zero and less than 
one. For this reason, the combined scores were then forced into a range from zero to 
one through a similar linear interpolation process to that used for the subattribute 
scores. Again, the highest combined score was given a one, and the lowest a zero. 
This assured that at least one architecture in each "If' scored a one or a zero. 
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TABLE 3.2.6-1- PERCENT OF FLIGHT DELAYED 
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TABLE 3.2.6-1.- PERCENT OF FUGHT DELAYED (CONCLUDED) 
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3.2.7 Environment 


3.2.7. 1 Definition 

The NIT's definition of the Environment attribute is: 

"The degree to which a given architecture has a long term effect on the 
Earth's environment during the course of nominal operations." 

Note that this definition is meant to exclude manufacturing processes and 
materials, also excluded are abort situations where the immediate preservation of 
human life is assumed to take precedence over any potential environmental 
damage. 

Effects on the environment can result from several distinct mechanisms. The 
major groupings are discussed in the following paragraphs and include launch 
vehicle effluents through the atmosphere, facilities associated with operations, 
power required for ground operations, and space debris. 

a. Environmental Effect of Launch Vehicle Effluents Through the Atmosphere.— 
The exhaust products from chemical propulsion may produce local and global 
effects that can be detrimental to life. In addition to the direct impact of acids, 
halogens, trace heavy metals, etc., in the effluent, a number of secondary effects 
and reactions are known to occur. 

The work performed under the auspices of an American Institute of 
Aeronautics and Astronautics (AIAA) workshop entitled "Atmospheric Effects 
of Chemical Rocket Propulsion", held in Sacramento on June 28-29, 1991, 3 
formed the basis for much of the numeric data used in the HTS study. The 
limitations of this work should be noted; in particular, the exit plane, 
equilibrium chemistry that was modelled fails to account for the fact that much 
of the important chemistry (with regards to detrimental effluent species) occurs 
before and after the exit plane. Also, insufficient time exists for all but the fastest 
reactions before the exit plane - this tends to be insignificant for propulsion 
calculations, but not for precise exhaust chemistry characterization. 

Environmental effects also vary as the vehicle flies through different zones in 
the atmosphere. For example, HQ deposition is a major concern at high 
altitude where ozone depletion is the issue; at low altitude, heavy metal 
particulate deposition would be a concern. Ideally, the measurement of 
environmental impact in a future study would account for the exhaust products 
versus altitude. 
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b. Environmental Impact Resulting from Operations Facilities.- Attempts to 
quantify environmental impact as related to facilities is divided into three 
categories. The first is a grouping of construction of facilities sites (primarily 
buildings) exclusive of launch and landing sites that are characterized by a large 
human presence for significant periods (power /water /sewer utilization and 
parking facilities). The second grouping is related to the actual launch site, 
arbitrarily defined as the area bounded by a security fence, where there are areas 
of biodisplacement and habitat loss, soil contamination (propellants, burning, 
and runoff from noise attenuation systems), and periods of high energy 
exposure (heat, noise, etc.). The third grouping is associated with land landing 
and recovery facilities involving large areas of biodisplacement or habitat loss 
and runoff pattern alteration. 

c Environmental Impact Resulting from Power Required for Ground Processes.- 
If the boundary of the space transportation system encompasses the entire range 
of activities related to its operations, consideration must be given to the 
potential impact that is related to the production of electrical power needed to 
support all phases of activities. Specifically, production of propellants involves 
large power requirements that may require additional generation capability 
above and beyond what the regular social infrastructure would dictate. For the 
time frame covered in this study, power generation will continue to be 
dominated by thermodynamic conversion technologies (coal, oil, or fission) that 
produce significant quantities of effluents that can contribute to smog, acid rain, 

etc. 

d. Space Debris - Most new programs, such as NLS, are making an early, concerted 
effort to minimize either the amount of hardware that stays on orbit and/or the 
degree of fragmentation and degradation that can be expected during space 
operations. 


3.2.7.2 Measurement of the Attribute 

A full simulation of environmental impacts related to launch vehicles is 
significantly beyond the scope of this study. A simple, consistent, and traceable set of 
metrics was developed to quantify differences between elements or architectures. 
These measurements are described by impact category as discussed previously. 

a. Environmental Effect of Launch Vehicle Effluents Through the Atmosphere.- 
An attempt was made to derive a weighted score for each exhaust product based 
on a perceived environmental impact. This net vehicle score implies a higher 
value is 'worse' than a lower one. In this simplistic approach, five key types of 
environmental concern were simultaneously considered: 
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• Ozone depletion - destruction of the Earth's protective ozone can be hastened 
by the introduction of species that break down O 3 into 02 - Most significantly, 
HQ from solid rockets acts as a catalyst. 

• Acid rain - one of the largest contributors to acid rain is rocket exhaust and 
the production of NOx- In this case, N 2 , normally considered benign as the 
largest constituent of the Earth's atmosphere, is artificially weighted higher to 
reflect NOx production. 

• Cloud nucleation - studies of high altitude aircraft contrails has shown a 
correlation between cloud cover and surface temperature and light levels 
(and subsequent oceanic biology levels). Water, OH, H, and H 2 molecules, as 
well as dust (trace elements in exhaust), can contribute to cloud nucleation. 

• Greenhouse gases - there are a multitude of anthropogenic sources of 
greenhouse gases. Rockets that burn hydrocarbon fuels will add these gases 
directly to the atmosphere. 

• Particulates - heavy particles can alter soil chemistry and biology (particularly 
at the launch site) and can adversely affect marine life. Solid rocket exhaust 
contains several heavy metal compounds. 

For the purposes of this study, the impact factors used in developing a 
weighted score (see System Results) considered the above effects. 


st Product 

Impact Factor 

Rationale 

CO 

1.7 

greenhouse gas 

CO 2 

1.5 

greenhouse, many sources 

h 2 

0.1 

secondary effects 

h 2 o 

0.3 

cloud nucleation 

HC1 

5.0 

O 3 depletion, acid rain 

n 2 

0.3 

acid rain (NOx) 

OH 

0.1 

secondary effects 

H 

0.1 

secondary effects 

AI 2 O 3 

3.0 

particulates 


A more rigorous approach to developing these impact factors would almost 
certainly change the weighted results. Any conclusions related to planning 
transportation elements based on an environmental attribute must be viewed as 
preliminary. 

b. Environmental Impact Resulting from Operational Facilities - In looking for a 
correlation between facilities and space transportation size or type, a survey of 
historical and existing systems was conducted. It was quickly apparent that, 
even for similar type systems, simple relationships do not exist. Factors such as 
local topography, operational philosophy, and time period seem to have a more 
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significant effect than, say, gross liftoff mass. Given the large uncertainty that 
would accompany any prediction of future systems’ facilities, it was deemed 
inappropriate to use any simple method for comparing a given architecture's 
environmental impact as it would relate to the facilities employed. 

c. Environmental Impact Resulting from Power Required for Ground Processes- 
As was the case in trying to correlate facilities with environmental impact, 
attempts to relate the power required for a given element with its size, payload, 
or other feature proved inconclusive. Based on these cursory investigations, it 
was decided to exclude "power required" as a factor in determining 
environmental impact. 

d. Space Debris.- Given the trend towards design practices which should limit the 
degree of additional debris caused by the launch of any new system, it is difficult 
to predict with any certainty what any random mission will contribute to the 
orbital debris environment. For the purposes of this study, specific 
characterization of debris contribution was dropped from further consideration. 


3.27.3 System Results 

The environment attribute scores by element are shown in Table 3.2.7.3-1. The 
effluent masses are in klbs. The bottom line "score" is derived by multiplying each 
effluent specie mass per launch by the impact factor, as discussed previously, and 
summing the number of flights to arrive at the architecture-level value. 


TABLE 3.2.7.3-1.- ENVIRONMENT DATA BY ELEMENT 


Exhaust 

Product 

Space 

Shuttle 

Shuttle 

Evol. 

Atlas 

E 

Atlas I 

Atlas 

II 

Atlas 

HAS 

Delta 

II 

NLS- 

20 

NLS- 

50 

NLS- 

HL 

Beta 11 

CO 

574.6 

625.5 

81.5 

100.1 

112.8 

128.8 

125.2 

0.0 

0.0 

542.6 

0.0 

C02 

84.2 


67.7 

83.1 

mm 

95.8 

76.6 

0.0 

0.0 

482 

377.5 

H2 

102.8 

90.6 

4.8 

5.9 

6.6 

8.2 

6.6 

11.8 

58 2 

108.8 

11.0 

H20 

1735.4 

2286.7 

101.1 

124.1 

140.0 

146.2 

70.4 

331.2 

1628.2 

1813.9 

481.9 

HC1 

502.6 

0.0 

0.0 

0.0 

0.0 

14.0 

31.4 

0.0 

0.0 

479.9 

0.0 

N2 

208.8 

0.0 

0.0 

0.0 

0.0 

5.6 

17.8 

0.0 

0.0 

197.8 

0.0 

OH 

0.8 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

4.8 

0.0 

H 

0.8 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

2.4 


A1203 

720.0 

I 0.0 

0.0 

0.0 

0.0 

20.0 

450 

0.0 

0.0 

851.3 

U.U 

Total Mass 
per Flight 
(klbs) 

3930.0 

3521.6 

255.1 

313.2 

353.2 

418.6 

373 

343 

1686.4 

4049.7 

870.4 

Score 

6023 

2079 

254; 

308 

347 

510 

633 

34 

169 

6203 

616 
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TABLE 3.2.7.3-1- ENVIRONMENT DATA BY ELEMENT (CONCLUDED) 


Exhaust 

Product 

Titan 

II 

Titan 
11 + 
GEM 

Titan 

III 

Titan 

IV 

SRM 

Titan 

IV 

SRMU 

Titan 
IV 14* 
core 

Titan 

IV 

LRB 

MLS-X 

MLS- 

HL 

SSTO 

AMSC 

CO 

11.3 

51.7 

220.7 

284.2 

3263 

342.7 

624 

0.0 

0.0 

125.2 

0.0 

C02 

30.5 

60.0 

92.0 

111.0 

1172 

174.2 

217.2 

0.0 

0.0 

76.6 

0.0 

H2 

15.9 

5.1 

20.7 

26.6 

30.4 

32.6 

8.4 

582 

582 

6.6 

8.0 

H20 

146.4 

120.3 

200.2 

243.6 

260.1 

370.6 

421.2 

16282 

16282 

70.4 

2232 

HC1 

0.0 

31.5 

229.2 

230.6 

267.5 

267.5 

0.0 

0.0 

0.0 

31.4 

0.0 

N2 

114.9 

148.5 

177.6 

276.8 

292.4 

433.3 

537.0 

0.0 

0.0 

17.8 

0.0 

OH 

0.0 

0.1 

0.3 

03 

0.4 

0.4 

0.0 

0.0 

0.0 

0.0 

0.0 

H 

0.0 

0.1 

0.3 

03 

0.4 

0.4 

0.0 

0.0 

0.6 

mg 

0.0 

A1203 

0.0 

45.0 

254.1 

330.0 

| 382.8 

382.8 

0.0 

0.0 

0.0 

45.0 

0.0 

Total Mass 
per Flight 
(klbs) 

319.0 

462.3 

1195.1 

1503.4 

1677.5 

2004.5 

1807.8 

1686.4 

1686.4 

■ 

2312 

Score 

116 

528 

2497 

2903 

3334 

3500 

1591 

169 

169 

633 

23 


3.2.7.4 Utility Curve 

The lowest environmental score within an "If" has a utility value of 1.0 and the 
highest environmental score within the same "If" has a utility value of 0.0. 
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3.2.8 Availability 


3.2.8.1 Definition 

Availability defines a system's ability to meet launch schedules for planned and 
unplanned missions. Different communities have evolved different approaches to 
defining and measuring equipment availability. Some define it as readiness for 
planned use, some for random or on-demand use. This is a crucial distinction - the 
measurements are quite different — and it led us to define and measure availability 
as the average of both. Therefore, Availability has two subattributes: Available 
Time Fraction (ATF) and Response Time. 

a. The ATF defines the ability of a system (booster plus spacecraft, but not payload) 
to meet planned mission schedules. It counts the normal mission preparation 
activities as Available Time, then estimates, as Unavailable Time, the delays in 
these activities due to five factors: (1) unscheduled maintenance, (2) facility 
delays, (3) logistics delays, (4) major modifications, and (5) fleet standdowns or 
groundings. It is essentially a measurement of ground- processing reliability. It 
is not dependent on the length of ground-processing time, only the probability 
that this time will be exceeded. 

b. Response Time is defined as the nominal time to prepare a system to launch an 
unplanned payload. It gives credit to a system with a short ground-processing 
time. 


3.2.8.2 Measurement 
a. ATF 

System Measurement - The data needed to measure this subattribute consists, 
first, of the duration of each part of the normal processing flow summed (taking 
into account parallel activities) to total Available Time. Then an accurate 
estimate is needed, for each of the five factors listed above, of the probability of 
its occurrence and the average duration of each occurrence. The product of 
probability times duration gives an average number of days per mission that the 
vehicle would be unavailable due to that delay factor. The sum of these five 
times is Unavailable Time for that vehicle. 

The ATF for a single system is then calculated as Available Time/ (Available 
Time + Unavailable Time). 

Architecture Calculations.- First, the increase in ATF due to the presence of 
multiple systems (e.g., four Space Shuttles) is calculated: 
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(1) The Unavailable Time Fraction (UTF) is calculated as 1-ATF 

(2) Architecture UTF = System UTF/the square root of the number of Systems 

(3) Architecture ATF = 1 -Architecture UTF 

Finally, the ATF’s for multiple systems in an Architecture are combined as 
above. 

b. Response Time 

System Measurement - The normal processing flow times, as used in ATF, are 
used to measure Response Time. For a single system, the longest Response 
Time (RTmax) is the total processing time (the vehicle is assumed to be in flight 
when needed for an unplanned mission.) The shortest Response Time 
(RTmin) assumes that the system has completed preflight preparation up to the 
time of payload integration; only integration and prelaunch processing times are 
counted. System Response Time (RT) is the average of these two times. 

Architecture Calculations .- With multiple systems in an architecture, the 
response time for which a 50-50 probability exists decreases from the average 
toward the minimum. This can be expressed by the equation: Architecture 
Response Time = RTmin + (RTmax - RTmin) /n+1, where n = the number of 
systems. Since the number of systems may vary from year to year, the value 
must be calculated annually and averaged. 

3.2.8.3 Utility Curves 

The preliminary approach was to rank the architectures relative to one another. For 
each subattribute, its score was converted to a value between 0 and 1 by the equation: 
(Score-Lowest Score) /(Highest Score-Lowest Score). The architecture final score was 
the average of the two subattribute scores. Since some insight is lost by this 
averaging, the raw scores for each system were to be provided as well. 

This attribute was dropped due to the complexity of estimating all the unavailable 
times for new systems with no historical data. 
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3.2.9 Mission Growth Potential 


3.2.9.1 Definition 

Mission Growth Potential is the ability of an architecture to enable specific new 
desirable mission types which are not currently baselined. 

This attribute rose out of the observation that the HTS mission model had no 
human missions to inclinations other than 28.5°, of durations longer than 7 days, to 
altitudes higher than 220 nautical miles, or with room onboard for "passengers." It 
was felt that some of these mission types were perceived as desirable by the 
customer, even though none are absolute requirements. The capability of each 
system and architecture was measured to enable these missions. 


3.2.9.2 Measurement 

The Mission Growth Potential score is the sum of three subattribute scores, 
measured for each system: 

a. Inclination 

The largest inclination change from 28.5° that can be reached is determined. A 
score is assigned based on a linear formula which yields 0 for 28.5° and 1 for 110° 
(Sun-synchronous) . 

That score is then multiplied by factors which express the system's payload and 
altitude capability at this highest inclination. The upper limits for which these 
multipliers give credit were determined by consensus as robust, but achievable. 
The multipliers are: a multiplier for payload capability -1 for no payload, 2 for 
30 000 lbs. A multiplier for maximum altitude achievable -1 for 150 n.m., 2 for 
400 n.m. A third linear multiplier is used for the number of years the system is 
available in this architecture: 1 for 1 year and 2 for 20 years. Twenty years was 
chosen because the first new human system IOC is scheduled for 2000; the Space 
Shuttle is not given credit for being in use prior to that year. 

Example: Space Shuttle in Option 1 can reach 57°, carries 19 000 pounds to that 
inclination, can reach 324 NM, is available more than 20 years; 
score = 0.5*1.63*1.7*2 = 2.77. 


b. Duration 

The number of days this vehicle can remain in a standard orbit with a standard 
payload and crew is determined. A score is assigned which yields 0 for 7 days 
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and 1 for 30 days. A multiplier is used for the number of years the system is 
available in this architecture, as above. 

Example: Space Shuttle duration now is 16 days; score = 0.4*2 = 0.8. 
c. Passengers 

The number of people that can be carried in excess of (four + vehicle crew) is 
determined. A score is assigned which yields 0 for 0 extra people, 1 for 4. A 
multiplier is used for the number of years the system is available in this 
architecture, as above. 

Example: Space Shuttle carries vehicle crew of 3 + 4 payload crew; 
score = 0*2 = 0. 


Separate scores for Inclination, Duration and Passengers are calculated as above for 
each human system in the architecture. For each subattribute, the highest system 
score is selected. The three are summed for the raw architecture score. 

In the above example. Space Shuttle is the only human system in Option 1; its raw 
score is 2.77+0.8+0 = 3.57. 


3.2.9.3 Utility Curves 

A utility curve divisor was to be used to reduce the raw scores to a fraction between 
0 and 1. The probable divisor was the highest architecture raw score. 

This attribute was deferred because of its low ranking. If it was ranked higher, there 
might have been a tendency to overdesign new systems to score well here, with a 
corresponding impact on the other attributes. 
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3.2.10 Resiliency 


3.2.10.1 Definition 

Resiliency is the ability of an architecture to exceed the flight rate requirements of a 
given architecture to work off the backlog resulting from a standdown. This 
attribute does not explicitly consider the resiliency benefits which result from an 
architecture with alternate access (i.e., where another system can perform the 
missions of a grounded system) because traditionally, launch systems are not 
interchangeable. 


3.2.10.2 Measurement 

One difficulty in measuring a system's resiliency is determination of the standdown 
times induced by various failures and simulating the occurrence of these failures 
throughout a mission capture analysis. This would require a complex Monte Carlo 
simulation and detailed Failure Mode and Effects Analysis of the vehicles sub- 
systems. A more deterministic methodology was sought to measure resiliency based 
upon the ground-processing system's margin. The selected methodology involves 
measurement of the nondimensional recovery launch rate factor (S). It is a measure 
of the excess nominal capacity plus allowable surge of the systems ground segment 
(see Figure 3.2.10-1). The excess nominal capacity is the remaining capability of a 
system after it has performed the required missions. The surge capacity is the 
difference between the maximum attainable launch rate and the designed capacity of 

the system. 

-Max. Attainable 
Launch Rate 
-Designed 
Capacity 

- Average 


[llllllllllllllllll 
Surge Capacity 



Flight Rate Requirements! 


Year 


Calculation : 

S = (Surge Availability + Flight Rate Requirement)/Flight Rate Requirement 


Where: 


Surge Availability = Excess Nominal Capacity + (0.2) (Surge Capacity) 


Figure 3.2.10-1.- Recovery launch rate factor measurement. 
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The recovery launch rate factor represents the ability of an architecture to exceed 
nominal operations without constructing new processing or launch facilities. It 
does not prohibit temporary manpower increases (e.g., second and third shifts or 
extended work days or weeks), however, it does limit surge operations to an average 
of 20 percent of total available work time (deemed to be a reasonable ground crew 
workload). 4 The assumption is that new employees will not be used to meet surge 
requirements because of the unpredictability of standdowns and the long training 
time required for new employees. 

Since architectures are to be comprised of multiple systems, the total resiliency is the 
flight rate- weighted average of each systems measure, based upon its share of the 
total mission capture. This methodology allows for the time phased increase or 
decrease in resiliency resulting from the ramping in and out of different systems. 

3.2.10.3 Utility Curves 

One suggestion for a resiliency utility curve would give a score of 1.0 for a system 
that has a recovery launch rate factor greater than or equal to 1.5. This means a 
system can increase its flight rate capacity by 50 percent while in a surge mode (i.e., it 
can work off the backlog created by a standdown in twice the duration of the 
standdown). 

Another method would give an architecture with the greatest resiliency a score of 
1.0 and the least, a score of 0.0. All other architectures would be linearly separated 
based upon their relative score. This would make all resiliency measures relative to 
each other and not absolute. 

Establishing a minimum value of S for a resilient architecture or system is difficult 
because these requirements can only be determined by considering the availability 
and reliability of the systems in each architecture. In other words, a system with low 
reliability will need a higher resiliency so that it can work off backlogs induced by 
the standdowns during failure analyses and resolution. On the other hand, a system 
with a high reliability will not need a high resiliency because the likelihood of a 
failure requiring a standdown will be less. 
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As a final note, systems with a large share of their missions dedicated to commercial 
flights may have an artificially high measure of resiliency (e.g.. Atlas). This has 
resulted from not including the commercial missions in the "If" Scenarios. 
However, if you assume that the government can expropriate (take control of) all 
space launch operations in the event of a crisis, then resiliencies may be compared 
equally. 

The NIT determined that this attribute was not a discriminator relative to other 
highly weighted attributes such as cost, safety, and probability of mission success. In 
order to dedicate more effort to the other attributes and analyses, this attribute was 
deferred to follow-on activities. Therefore, a utility curve was not selected at this 
time. 
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3.2.11 Dependability 
3.2.11.1 Definition 

The ability of an architecture to meet its own launch schedules. 


3.2.11.2 Measurement of Attribute 

There are three subattributes, each involving specific launch-time criteria: 

(1) "Annual": probability of achieving at least Npeak launches per year, where N pea k 
is the greatest number of launches required in a single year for this launch 
system in the architecture and "If" is being evaluated 

P N = Probability of >Npeak launches per year 

(2) "Launch Day": probability per launch of <3 days slip after a launch date is 
specified 

Pd = Probability of ^3 days slip per launch after date set (T-l week) 

(3) "Window": probability of launching within 10 minutes of planned launch time 

Pm = Probability of <10 minutes (after T-24 hours) slip per launch 

The major factors affecting dependability are weather, fleet sizes and processing 
facilities, and complexity and reliability. The Dependability Attribute for an 
architecture will be improved by increasing the number and duration of built-in 
holds that are incorporated into processing schedules and countdowns; by increasing 
the reliability of GSE and obtaining back-up GSE, by providing margins in vehicle 
equipment and on-board redundancy in excess of that required for launch, and by 
planning for adequate staffing of support personnel and working normal shifts (i.e., 
overtime is also a margin that may be invoked for meeting schedules). 

The calculation of the foregoing probabilities was assigned to the AET, using 
extensive databases of site-specific weather and vehicle-specific systems data. In 
order to determine probability of launch susceptibility to weather and hardware 
delays, the following were input to the AET: 

p D (weather) = probability of acceptable weather at time launch window opens 
- considering all aspects, including pad, abort sites, and winds 
aloft 
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p D (hardware) = probability of no launch scrub on day of launch due to 

hardware - including GSE, flight equipment, com net, facilities, 
etc. 

p M (hardware) = probability of no scrub during 10-minute launch window 
The AET then calculates the following: 

pD = pD(weather) * pD(hardware) = probability of launching on a given day 
P d (D< 3 days) = 1 - (l-p D ) 3 

Note: exponent reflects three successive day criterion. This formulation 
assumes slips are one day at a time, and that two or more day slips are so 
infrequent as to be insignificant. Historical distributions should be used when 
available. 

Pm (M<10 minutes) = p M 

Note: weather effects are totally reflected within P D , and do not affect Pm- 

Using the peak number of launches, N pea k, of the relevant human system in a 
single year needed to support the given "If' in the architecture under evaluation, 
p N (>N) values are determined and inserted into a table in the AET data base, for 
N = 1 through 20. 

p N (£N) can be established from actual experience, or it may be calculated based upon 
the following idealized model: 

P N (>N) = f [number of days available per year/ 

(number of days per launch x number of launches)] 

Minimum possible launch rate per single-string system: 

Pn = 1, when N m i n £ (365 - T w - T p /i)/(T p +33) 

Maximum possible launch rate per single-string system: 

P N = 0, when N max > (365 - T w - T p /i)/ (T u +T p + d - T m ) 


Where: 

N = number of launches /yr 

T p = minimum number of days between consecutive launches 

(pre-flight processing time + mate to booster + pad time + countdown + 
avg. flight time + post-flight processing) 
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d = standard deviation of T p 

T u = unscheduled lost time (unplanned maintenance; equipment down 
time) 

T m = margin per launch that can be captured through increased 
use of resources (cost, overtime, special equipment, etc.) 

T w = number of days per year with unacceptable weather = 365 * q D ( weather) 

Tp/i = number of days lost per year due to P/L or other non-t transportation 
delays (including strikes, continuing resolutions, holidays, etc.) 

Other values of Pn must be computed by statistical procedures, using a probability 
model for types of interruptions requiring use of margin times (T m ), fleet size, 
bottleneck facilities, etc. At the point at which work on this Attribute was 
discontinued it had not been decided whether an exact formulation, a Monte Carlo 
approach, or a curve approximated from engineering judgment would be employed 
for accomplishing this. These probabilities are also to be multiplied by the number 
of duplicated facilities when taken through the critical path. 

Finally, the AET calculates P(N>N pea k) from its Pn(>N) look-up table and the value 
of Npeak- 


3.2.11.3 Utility Curves 

There are no explicit utility curves associated with the Dependability Attribute. 
Rather, the subutility components of the final attribute value are calculated by the 
AET, weighted, and summed internally, as indicated in the following steps. Using 
input values of subutility relative-weighting factors (wn, wd, and wm - see below), 
and AET-calculated subutilities from curve fits of Utility vs. Probability, an overall 
utility value for each launch system is calculated. 

The overall Utility is thus the weighted sum of the three subutilities: 

Utility of Launch System = U x = (wn Un + wd Ud + wm Um)/(wn + wp +wm) 

In the process, each launch system is categorized as to whether it is human-tended, 
untended-critical, or untended-noncritical. The AET then calculates an overall 
Utility for the architecture under consideration using the utilities for each separate 
launch system and additional weighting factors that take into account the relative 
importance of human ns. untended, critical payloads, etc. These weighting factors 
were consensually established at the following values: 
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f m = weighting factor for human systems = 10 

f C/U = weighting factor for critical, untended payloads (e.g., because of a need to make 
a certain launch window, or to resupply logistics to SSF) = 4 

f n u = weighting factor for non-critical untended payloads (no launch urgency) = 1 

Ultimately, the aggregate Utility is the weighted sums of the utilities, expressed as 
follows: 

Utility of Dependability = (f m U m + f C/U U c , u + f n ,u U n , u )/(fm + fc,u +fn,u) 


3.2.11.4 Status 

Dependability was one of the attributes dropped at the mid-point of the HTS Study. 
The effort involved in calculation of the attribute values was deemed excessive 
within the funding constraints of the overall study relative to other, more 
significant, attributes. The foregoing discussion describes the planned treatment of 
the Dependability Attribute at the time work was discontinued on it. 
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3.2.12 Alternate Access 


The "Augustine Committee Report" 5 in its Recommendation #11, advised that 
"NASA initiate design activity so that human activity in the Space Station could be 
supported in the absence of the Space Shuttle ..." The HTS study addressed the 
concept in two ways. The first was as one of the 1 0 original attributes, discussed 
herein; the second was via the preparation of architectures contrasting with respect 
to the presence or absence of such a capability to continue personnel SSF operations 
in the absence of the Space Shuttle (see section 3.3.7). 


3.2.12.1 Definition 

The definition of Alternate Access is the ability of an architecture to continue or 
resume personnel and/or cargo flights in a timely manner to SSF in the absence of 
the primary system for such flights. 


3.2.12.2 Measurement of Attribute 

Quantification of Alternate Access was in terms of the number of days required 
from the unexpected termination of primary system availability until the 
appropriate alternate personnel or cargo system was projected to be ready to launch. 


3.2.12.3 Utility Curves 

Piecewise continuous utility curves for both personnel and cargo Alternate Access 
were developed (Figure 3.2.12.3-1). Each of these decreased slowly until the delay in 
regaining access via the alternate method became so long as to (a) require use of an 
ACRV for crew evacuation in the human situation, or (b) result in degradation of 
SSF attitude control capability due to propellant depletion in the cargo situation. 

For greater time delays, the utility curves yielded smaller values going to zero at an 
18-month delay. The discontinuity in the human curve reflected study estimates of 
the programmatic impact, and national and NASA "loss of face" from a forced crew 
evacuation. The 18-month cut-off was based upon the estimation that any prime 
system standdown was unlikely to last more than two years. As delays in resuming 
operations via the Alternate Access system approached that time value, there would 
be progressively less benefit from and pressure to use it. 
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Careo 

NSFP 
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Figure 3.2.12.3-1- Alternate access (composite). 


The resulting personnel and cargo utility values were then "derated" individually 
by a factor involving the failure rates of any elements common to both the primary 
and alternate systems, divided by the overall failure rate of the primary system. The 
derated personnel and cargo functions were then arbitrarily weighted 80/20, 
respectively, and summed on a yearly basis. 


3.2.12.4 Status 

Alternate Access was one of the attributes dropped at the mid-point of the HTS 
Study. Lacking the means for and a consensus to conduct a Monte Carlo (or similar) 
simulation of launch vehicle failures, there was no way that the benefits of 
providing Alternate Access within an architecture could be quantified. The attribute 
itself was assigned a relatively low weight by the NIT. When combined with the 
heavily weighted Cost Attribute, Alternate Access was overshadowed by the 
increased cost of providing it. Consequently, Alternate Access was dropped as an 
attribute, but remained as a feature for the subjective comparison of some 
architectures. 
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3.3 TASK 3 - ARCHITECTURE ANALYSIS AND EVALUATION 


3.3.1 Task Approach 

To understand whether a particular vehicle design option should be built, it must be 
viewed in the context of the other elements which will be used to provide the total 
transportation capability. This grouping of transportation elements is called an 
architecture. Because an evaluation of a design option’s characteristics and 
attributes can only be evaluated in the context of what mission requirements it 
meets and which vehicles are available to carry a required payload, it is impossible 
to evaluate, for example, a PLS without an architectural context. 

An architecture is defined as the total group of elements (launch vehicles, boosters, 
capsules, etc.), with their associated capabilities and infrastructure, which are 
providing transportation access to space over some defined period of time. As will 
be described below, this architecture set was constructed by selecting a series of 
considerations important to the customer, and then selecting the group of elements 
which, in conjunction, provide a set of launch capabilities. The elements in the 
architecture were then manifested to meet the HTS Needs Model, and attribute 
values (cost, safety, risk, etc.) for each architecture were calculated to provide a 
quantitative assessment of how potential concepts fared relative to one another. 

Figure 3.3.1-1 is a flow chart to show how data was used in the study and the 
relationships between data input and output in the process of an architecture's 
evaluation. 
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Figure 3.3. 1-1- Study data flow. 
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3.3.2 Architecture Options Development 


3.3.2.1 Development Methodology 

The architecture set for the HTS study was developed to gain understanding into a 
set of considerations or issues which will affect the design of the next human space 
transportation vehicle. These considerations are described in section 2.2.3. The 
architectures were comprised of elements which provided crew and cargo delivery 
and return functions from the present to 2020. 

To understand the impact of these considerations on future system options, a set of 
architectures was compared for each consideration. For example, to understand the 
separation of people and cargo, three architectures were constructed. The first kept 
people and cargo together by using the Space Shuttle or a miniature "Space Shuttle" 
for Human Receipt at Destination payloads. The second completely separated the 
two, with the crew going to orbit in a personnel carrier, and the cargo aboard a 
separate ELV. The two would then be required to rendezvous on orbit to complete 
the mission. The third separated people and cargo into distinct crew and cargo 
modules which were launched on the same launch vehicle. These three 
architectures were then manifested and their attributes were evaluated. A similar 
approach was taken for the other considerations. 

Approximately 30 distinct architectures were identified for study, which was 
subsequently narrowed to 18 after review and consensus from the HTS Study Team. 
From this group, three were subsequently deferred due to the unavailability of data 
on the primary human elements of that architecture. For each architecture, 
elements were identified which would provide people up (delivery), people down 
(return), cargo up, and cargo down functions. Elements were phased in five-year 
increments from 2000 to 2015. This was a simplifying assumption since it was 
believed that a 1 or 2- year difference in vehicle IOC would have a small impact on 
the overall architecture cost, risk etc. No vehicles were phased in or out prior to 
2000 since it was unlikely that NASA would introduce new systems prior to this 
date. Figure 3.3.2.1-1 shows an example of a template for a representative 
architecture and Figure 3.3.2.1-2 provides a summary of the architectures considered 
in the study. A detailed explanation of these architectures is provided in sections 
3.3.5 to 3.3.11. Finally, for each architecture, a set of manifesting philosophies were 
developed which governed how an element would be used. This allowed the team 
to assign priority, consistent with the architecture intent, to different vehicles which 
could carry the same payload. 
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1 2010 1 

1 2015 1 

People 

Up 

• Space Shuttle 
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•Space Shuttle 

• Space Shuttle 

• Space Shuttle 


Figure 3.3.2. 1-1- Example of an architecture template. 
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I Architecture BaseHne | ■■■■■■■’ ■■■ ■■ - Continued use of current systems; ACRV for SSF PMC (Arch #1) 


[Architecture Consideration* 
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Evolve Current Systems (Arch #2) 


Alternate Access 



Cargo up only; use of domestic systems w/ NLS (Arch #3) 

Crew & Cargo up only; use of domestic systems w/ MR Titan (Arch #14) 

Crew & cargo; use domestic systems w/ personnel & cargo vehicles (Arch #4) 

Crew & cargo; use of foreign -developed systems (Arch #15)- Deferred due to lack of data 


| Separation of People and Cargcf 


E 


Crew & cargo together using Crew & Logistics Vehicle (Arch #5) 

Crew & cargo launched separately using personnel & cargo vehicles (Arch #6) 

Crew & cargo launched together using attached personnel & cargo vehicles (Arch # 7) 


| Which Manned Booster?] " 


Use of NLS (Arch #13) 

Use of Man-rated Titan (Arch #14) 

Use of medium-lit Manned launch System (Arch #6) 
Use of heavy-lift Manned Launch System (Arch #5) 
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Build ACRV, but phase out after personnel vehicle IOC (Arch #12) 
Build both ACRV and personnel vehicle together (Arch #13) 
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| Advanced Technology*} 
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Near-term, rocket- powered SSTO; Rockwell SDK) concept (Arch #8) 

Far-term, rocket-powered TSTO; LaRC AMLS concept (Arch #9) - Deferred due to tack of data 
Far-term, air-breathing SSTO; N ASP JPO NDV (Arch #1 0) - Deferred due to lack of data 


1 ^ w— Air-launched personnel carrier; Rockwell AMSC concept (Arch #1 6) 

New Concepts | } ■■■- Reusable ultralight personnel carrier; Martin Marietta concept (Arch #17) 

Advanced TSTO; Wright Labs Beta II concept (Arch #1 8) 


Figure 3.3.2.1-2.- Architecture summary. 
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In addition, other analyses, beyond the evaluation of the above considerations, were 
conducted. For example, to assess the impact of return cargo requirements, a group 
of architectures was selected and the needs model was modified by reducing return 
cargo requirements. The architectures were then remanifested and compared with 
the baseline results. 

The HTS architecture set is broad enough to gain insight into other considerations. 
For example, comparison of the reference architecture (continued use of current 
systems) with the architecture that adds the NLS gives insight into how many 
payloads could be off-loaded from the Space Shuttle onto the new launch vehicle. 
One could also gain insight into the effect of Space Shuttle system phase-out dates by 
comparing architectures with early and late Space Shuttle phase-outs. One should 
use caution, however, in trying to get absolute answers from these architectures 
(e.g., how many more Space Shuttles NASA should buy), since the architectures and 
the subsequent attribute scores are better suited for comparative purposes. In other 
words, the study is better suited to understanding architectural implications of new 
system alternatives compared to continued use of current systems It is not intended 
to answer detailed issues within a given alternative. However, sufficient accuracy 
and depth has been covered to meet the objectives of the HTS study. 


3.3.2.2 Architecture Manifesting Groundrules and Approach 

At the onset of the study, the study team defined a set of top level groundrules and 
assumptions for the mission capture analysis. These groundrules and assumptions 
are applied across all architectures consistently. Architecture-specific assumptions 
were also necessary and were created and approved by the study team on an as- 
required basis. Tables 3.3.2.2-1 and 3.3.2.2-2 list the general groundrules and 
assumptions, respectively. 

3.3.2.2.1 Mission capture and payload manifesting .- The General Dynamics 
TRANSIT (Transportation Systems Integration Tool) was used to perform the end- 
to-end mission model analysis, including system performance calculation, mission 
capture, and payload manifesting. Mission capture is the matching up of a certain 
mission or group of missions to the launch system while satisfying all mission 
constraints and vehicle constraints, including performance. Mission constraints 
include final destinations, payload mass and dimensions, or other operational 
considerations (e.g., multiple, identical payloads must be flown separately). Vehicle 
constraints include launch site, IOC, other availability limitations, cargo volume, 
performance to the destination orbit, etc. Only when the two sets of requirements 
are matched are missions "captured." When there is more than one vehicle that 
can capture a particular mission, other secondary criteria must be provided to help 
select between the candidate systems, such as cost-per-flight or system priority. For 
the study, the team selected the other criteria based on the intent of the architecture. 
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TABLE 3.3.2.2-1 - GENERAL MISSION CAPTURE GROUNDRULES 


The mission models used for mission capture were the "If Scenarios" 
defined by the HTS Study Team. 

Mission capture and payload manifesting used only those systems in the 
study-defined architectures. 

The mission model period is 1992 to 2020. 

• The NASA Mixed Fleet Manifest (August 1991) was used for 
flight rates between 1992 and 1997, while the HTS Mission 
Model requirements were used for 1998 and beyond. 

15 percent Airborne Support Equipment is added to all payloads, except 
for SSF logistics and ACRV. 

Both payload mass and dimensions must be observed during manifesting; 
when dimensions are not available, payload mass must still be observed. 

SSF logistics. Satellite Servicing and Science Sortie payloads can be 
resized to match new launch vehicle performance. 

Payload delivery must be accomplished in the years specified by the 
mission models. 

Human DOD missions were flown with the lowest cargo system 
capability available. 

In the early years, "Unmanned" payloads are limited to untended systems 
until new reusable systems such as the SSTO or TSTO are available to 
fly them. 

West coast Titan II total flights in any architecture will not exceed 55; 14 
being refurbished by MMC, 41 still in storage by the U.S. Air Force. 

• This constraint is lifted in Architecture 17, when it was 
assumed more Titan II’s are built for RUPC transport. 


ACRV payload and launch information in HTS CNDB was not up-to-date. 
Therefore updated ACRV delivery mass to include FSE & ASE: 

17,318 lbs; return mass is 16,188 lbs; dimensions are 15.67 ft length x 14.5 ft 
diameter. 

• Also, extend ACRV launch schedule from 2010 to 2020 
with similar traffic pattern for manifesting purposes 

SEI human flights in "If E" are dedicated flights. 
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TABLE 3.3.2.2-2.- GENERAL MISSION CAPTURE ASSUMPTIONS 


Only east a nd west coast launch sites were considered. 

For mission capture and payload manifesting purposes, system failures or 
standdowns were not accounted for , i.e., flight rate results exclude 
reflight consideration. Unreliability costs are accounted for in the life 

c ycle cost analysis. 

New systems phase out existing systems nominally over a 5-year period. 
Ramping was linear and based on maximum flight rate in architecture/ 
"If" scenario combination. It was not necessarily related to the system 

developm ent or program schedule. 

The EOS payloads of 30 000 lbs to sunsynchronous orbit may be split into 

sma ller pieces to fit on the Titan IV flying out of the West Coast 

Atlas E has only one vehicle left at this time; the remaining DOD Atlas E 
class payloads will go on either west coast Delta II, or new vehicles, e.g. 

NLS-20. 

X-ray background survey explorer in HTS Needs Model is destined for 200 
nmi, which is the only mission to this orbit; assume 

220 nmi for manifesting purposes. 

For those architectures having RPC replacing ACRV, one extra RPC flight 

is added in 2002 to enable transition from 4-to-8 crew SSF. 

For additional planetary missions beyond the current planning horizon, 
assume: 

• Delivery mass is nominally 12 100 lbs 

• Average C3 requirement is 0 km 2 / sec 2 - 


Payload manifesting, on the other hand, is the selection of additional payloads to fly 
on the flight of a given system once it has been chosen for the primary mission. 
Once the mission's and system's match-up has been determined, TRANSIT begins 
to manifest payloads together on the launch vehicles. The payload manifests for 
this analysis do not produce flight assignments such as those for the Space Shuttle, 
since (1) these are only projected payloads, and (2) payload compatibility, integration, 
and other issues have not been considered. 

Some payloads were resized to fit onto new launch vehicles. These were 

a. the SSF Pressurized Logistics Module (PLM), 

b. the SSF Mini-PLM (MPLM), 

c. the SSF unpressurized logistics module cargo, and 

d. all smoothed Satellite Servicing and Science Sortie payloads. 
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These payloads were broken up to best fit in the new vehicle, accounting for total 
mass and launch schedule. For example, with the 29 748 lb PLM requiring three 
deliveries every year, three Space Shuttle flights are required, each with additional 
payloads to maximize payload efficiency. But for an SSTO (Rocket) launch vehicle 
which has only a 15 000 lb capability to the SSF, the PLM is broken up into two 
modules of 

14 874 lb each, for a total of six flights per year. This was done to maximize launch 
efficiency while keeping the manifesting simple. 

Figure 3.3.2 .3 shows the general mission capture and payload manifesting steps. The 
figure shows five different payloads to be considered by the three candidate vehicles, 
depicted by their cargo bay and fairing. Based on the understanding of the mission 
objectives and requirements, the matching of mission and system determines which 
mission can potentially be captured by which system. Further tests by TRANSIT as 
to performance of the system to the mission destination, payload mass and 
dimensions, vehicle cargo volume, east and west coast launch constraints, system 
availability (year and maximum flight rate), etc., will determine if the system can 
capture the missions. 
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Figure 3.3.2.3.- Mission capture illustration. 
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Once the mission-to-system match-up is done, actual manifesting, i.e., putting 
payloads together with each other on the same flight, is done. Again, a series of tests 
are utilized to verify if the payloads can be put together on the same flight. Criteria 
for manifesting the tests include: 

a. Payloads with higher priority are considered first; this ensures that critical 
missions are provided before annual launch rate constraints take effect. 

b. Both the payload mass and dimensions must be within the system's capability 
(performance to destination orbit, cargo bay or fairing volume). If the launch 
mass efficiency is low because the payload size is large, the launch vehicle must 
still fly with low mass efficiency. 

c. Payloads allowed together on the same flight must have the same vehicle 
requirements, i.e., they must require the same service from the system. 
Otherwise, a detailed operational analysis must be performed to ensure the 
vehicle can maneuver onorbit, change plane and/or altitude, etc., to satisfy 
different mission needs. 

TRANSIT applies this generic mission capture algorithm to all architectures for 
each mission, vehicle system, and year in the mission model. At the completion of 
the run, the outputs are tabulated. They include mission-to-vehicle capture, listing 
of payloads on die same flight, manifesting efficiency, summary of flight results for 
each launch site, and number of required launch systems. This information is, in 
turn, used to determine the other flight-rate-weighted study attributes, including 
number of required launch vehicles, and their associated launch costs. 


3.3.3 Transportation Elements and Systems 

The process of populating the architectures with element or vehicle concepts was 
more difficult than developing the theme of the architectures themselves. A list of 
roughly 25 elements was identified which could be incor-porated into the 
architectures. Many of these elements were selected not only for their ability to fill a 
capability or function gap in some architecture set but also to incorporate concepts 
which are well known and have resources devoted to study them. For example, it 
was important to know how a PLS or an SDI SSTO vehicle fit into the spectrum of 
possible design and architecture concepts. In the end, most of the concepts which 
were of principal interest to the customer were incorporated. 
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Table 3.3.3 shows a summary of the elements used in the study. The table identifies 
in which architectures these elements appear, as well as their phase-in and phase- 
out dates. Small commercial vehicles (Pegasus, Taurus, Conestoga, etc.) and sound- 
ing rockets (Scout, Aires, etc.) were not considered in this study since it was believed 
that their use/ flight rates would have a negligible impact on an architecture's 
attributes. Detailed descriptions of these elements are provided in subsequent 
paragraphs. 


TABLE 3.3.3.- HTS ARCHITECTURE ELEMENTS AND OPERATION PHASES 


Earth-to- Orbit Architecture Options 


Systems 

1 

2 

3 

4 

5 

6 

7 

s 

9 

10 

11 

12 

13 

14 

16 

17 

i» 

Al Us IIAS 

92 

92 

92-10 

92-10 

92 

92 

92 

92 

92 

92 

92 

92 

92 

92 

92 

92 

92 _ 

Delta II 

92 

92 

92 

92 

92 

92 

92 

92 

92 

92 

92 

92 

92 

92 

92 

92 

92 

Shuttle 

92 

92 

92 

92 

92-05 

92-05 

92-05 

92-05 

92-10 

92-15 

92 

92 

92 

92 

92-10 

92-05 

92-10 

Titan IV 

92 

91 

92-06 

92-05 

92-05 

92-05 

92-06 

91 

91 

91 

92-05 

92-05 

92-05 

92 

92 

92 

92 

ACHV 

■m 

H2S 

o 

K3H 


flEUi 

m 

97 

97 

97 



97 

97 

97 

97 

97 

CTF/DeheH 


mm 



■ 

■ 

■ 

00 

00 

00 

mm 

m 


00 

00 


00 

CTF/AiImIIAS 





■ 

fl 


00 

00 

00 


fl 


00 

00 


00 

CTF/Trtan IV 

fl 



fl 



■ 

00 

00 

00 


HH 


00 

00 

00 

00 

Shuttle Evol W LR8 


00 


■ 

■ 


■ 

■fl 

■fl 


B 


HHI 


HI 

■ 

BB 

RCVW/ASRB 


00 










B 






AtlaaEvoL 


00 

B 

7.---P 






B 




BB 



' . H 

Titan EvoL 

If 

00 



■ 

■ 


■ 

■ 

fl 

Hi 


Hi 

1 

■H 

B 

B 

RPC/ UR Than IV+ 



■H 


m 







■ 






RUPC/Than 11+ GEM 
















00 


RPC/NLS-2 




00 





fl 


00 

05 

00 

■1 


BB 

fl 

NLS-1 



00 

00 







00 

00 

00 


“ ■ t ; 


fl 

NLS-2 



00 

00 



Hr 

H ; ^ 



00 

00 

00 




HH 

NLS-1 + AUS 

1 


00 

00 

■,'vl 


BBS 

jjS'/ 



00 

00 

00 




HI 

NLS-2 + AUS 

■ 


00 

00 


■ 

■ 




00 

00 

00 



fl 


NLS-3+ AUS 



05 

05 


iBjl 




sH 






fl 

fl . .. 

CIV/NLS-1 

■ 


00 

00 



i 




00 

00 

00 




| ■ • 

CIV /NLS-2 



00 

00 







00 

00 

00 

fl 


BB 

fl .. 

CRV/NLS-1 

| 



00 

1 



^H 

MB 








B 

RPC (CLVVMLS-HL 

1 






m 

mm 

m 

fl 

mam 







RPC/MLS-X 




P ■ v . 


00 




J A 




7 fl 




RPC/LRV/MLS-HL 


sip 


■ 



00 





MBs 


flfl| 



v . B 

MLS-HL 





00 

00 

00 




HB 

I 



H 

HH 

mm 

MLS-X 



■ 


00 

00 

00 





fl 

.. 1 



■P;- ’ 

fl 

CRV/MLS-HL 




m 

00 

00 

00 







| 

|B 

PSP 

HH 

LRV/CTF/Titan IV 











fl 



fl 

fl 


■*m 

■ 


SSTO (Rocket) 




m 




a 

■ 

■ 

B 

■ 

^^fl 

■ 

B 


BB 

SSTO (Air Breathing) 


§ 

• " . 




H 


fl 

10 



H 





TSTOLARC 





■ 


p, § 




■ 



BB 




TSTO WL/FIMC (BETA ID 



■ 




■ 

■ 




B 


fl 

BB 



AMSC 



HI 


HHI 

Hi 


■ 



B 





B 

B 


3.3-9 


Rev. E 















































3.3.3. 1 Space Shuttle 


System Description 

The Space Shuttle is NASA's only human ETO system at this time (Figure 3.3.3. 1-1). 
Performance specifications called for the ability to put 65 klb (18.2 mt) into a 100 nm 
(185 km) orbit inclined 28.5 degrees to the equator, 40 klb (18.2 mt) into a 100 nm 
orbit at a 90 degree inclination, and 25 klb (11.3 mt) into a 277 nm (513 km) orbit 
inclined 55 degrees to the equator. To meet abort requirements for polar launches, a 
1500 nm (2780 km) cross-range capability was required. The current Space Shuttle 
system consists of a reusable orbiter, an expendable ET, and two recoverable SRB’s. 
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Figure 3.3.3.1-1.- Space Shuttle mission profile. 
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Performance characteristics 


At present, there are four operational orbiters: Columbia (OV Orbital Vehicle -102), 
Discovery (OV-103), Atlantis (OV-104), and Endeavor (OV-105). The Space Shuttle 
Orbiter has a design life of 100 missions. Its crew compartment accommodates up to 
7 crew members and can handle 10 persons during emergency operations. The 
Orbiter s cargo bay is 60 ft long and 15 ft in diameter (18.5 x 4.5 m). It can carry 
payloads to and from orbits ranging from 100-600 nm (185-1100 km) in altitude 
(payload capacity as a function of inclination and altitude is given in Table 3.3.3. 1-1). 
Upon completion of its orbital activities, the Orbiter lands horizontally, as a glider, 
at a speed of about 312 fps (95 mps) and a glide angle of 18 to 22 degrees. 

TABLE 3.3.3.1-1.- SPACE SHUTTLE PERFORMANCE CHARACTERISTICS 


INCLINATION 

(deg) 

APOGEE X PERIGEE 
(nmi) 

PAYLOAD 

(klbs) 

28.5 

160 x 160 

54.0 

28.5 

220 x 220 

46.0 

28.5 

300 x 300 

37.0 

57.0 

160 x 160 

38.0 

57.0 

324 x 324 

19.0 


The Space Shuttle's propulsion is provided by the three SSME’s located in the aft 
fuselage and two SRB's. The SRB’s operate during the first 212 seconds. After 
thrust tail-off, they are jettisoned into the ocean for retrieval and refurbishment 
operations. Fuel for the main engines is carried in the ET, which is jettisoned 
shortly after SSME cut-off, at about 98 percent orbital velocity. In orbit, the Space 
Shuttle is propelled by the OMS contained in two pods on the aft fuselage. The 
Reaction Control Subsystem (RCS) is contained in the two OMS pods and a module 
in the Orbiter's nose section. The RCS provides attitude control in space and during 
reentry and is used during rendezvous and docking maneuvers. The Orbiter is 
constructed primarily of aluminum and is protected from reentry heat by the 
Thermal Protection System (TPS). The principal substructures of the Orbiter are the 
crew module, forward fuselage, mid-fuselage, payload bay doors, aft fuselage, engine 
thrust structure, wings, and vertical tail. 

During ascent, the Space Shuttle has four abort alternatives, depending on mission 
elapsed time when the failure occurs. They are: return to launch site (RTLS), trans- 
Atlantic abort (TAA), abort once-around (AOA), and abort-to-orbit (ATO). 
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Operational Facilities 

Space Shuttle operations involve three key NASA Centers* JSC (lead center, Orbiter, 
mission operations), KSC (launch, landing and refurbishment), and MSFC (SRB s, 
SSME's, and ET). In addition. Space Shuttle uses the Air Force's Dryden Research 
Center as a primary and backup landing site. Test facilities at the Stennis Space 
Center are used for on-going SSME life cycle and development tests. 

A typical Space Shuttle processing flow schematic, indicating facility dwell times, 
along with work day and shift information used in this study, is shown in Figure 
3.3.3.1-2. 

Attribute Values 

System input data related to each attribute, as well as system specific attribute values 
are discussed below. In most cases, system data is modified by flight rate or cost 
associated with the particular architecture and/or "If' being evaluated. However, 
some useful observations can be made at the system attribute level. These will be 
discussed following the presentation of the Space Shuttle system data. 

a. Human Safety.- Relevant system data for human safety consists of system 
characteristics that enable the crew to detach or escape from the main body of the 
system during ascent in the event of a mission failure. A single design feature 
(the slide pole) of the Space Shuttle (added after flight 51L) allows for crew 
escape from the Orbiter. However, its use is restricted to level, unpowered flight 
at subsonic speeds, which occurs at the end of each abort mode (except ATO) and 
near the end of the landing phase. It provides no relief during powered ascent. 
On the other hand, several abort options (described earlier) exist and can be used 
in the event of a non-catastrophic SSME failure. If an abort-to-orbit is executed, 
it is possible that the mission will be a success. The Space Shuttle does not have 
a means of aborting the crew should there be an SRB catastrophic failure. Other 
salient features include having the crew module in the same element as the 
liquid engines, but over 70 feet ahead of their location, and having the crew 
module parallel to the propellant tank, as well as to the solid rocket boosters. 

b. Funding Profile - Cost information provided to the HTS study team included 
the cost of new facilities, new Orbiters, variable and fixed costs per flight for each 
flight element, launch and flight operations, and NASA's Research and 
Program Management support. In addition, spread factors for each cost item 
were provided, identifying how much of the total cost was spent in the years 
preceding the need for flight date. Table 3.3.3. 1-2 presents a summary of this 
data. 
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Figure 3.3.3.1-2.- Space Shuttle operations flow schematic. 
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TABLE 3.3.3.1-2- SPACE SHUTTLE FUNDING PROFILE INPUT DATA 


SPACE SHUTTLE 
COST BREAKDOWN 
CATEGORIES 

TOTAL 

ORTFU 

COST 

($M) 
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30 
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12 
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23 

36 


l 
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23 
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■ 


58 

41 
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75 


16 

26 

26 

32 
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s 

75 
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5 

598 




■1 

100 

FLIGHT OPERATIONS 




7 

666 



IB 

E 

92 
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0 

327 








100 


c. Probability of Mission Success - A system description and flight profile contains 
the required input information for this attribute. In summary, the Space 
Shuttle has one liquid propulsion stage, three liquid engines (with engine out 
capability per the abort descriptions), and two solid motors used during the 
initial boost period. A mission profile and sequence of events is shown as part 
of Figure 3.3.3.1-1. 

d. Architecture Cost Risk (ACR).- Two of three subordinate attribute values for 
ACR are Technical Challenge and Program Immaturity. Since Space Shuttle is 
an operating system and is capable of meeting the needs without further 
development, it received the best rating (score of 1.0) on both scales. The third 
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component. Number of New Systems, is an architecture-level value. Space 
Shuttle's contribution to architecture scores for this component of ACR is zero. 

e. Launch Schedule Confidence (LSC).— As in ACR, there are three subordinate 
attribute values for LSC: Schedule Compression, Schedule Margin, and Delays 
due to unscheduled maintenance activities. Schedule Compression and Delays 
are architecture independent while Schedule Margin is architecture dependent 
since its values are a function of annual flight rates and available facilities and 
Orbiters. Space Shuttle's Schedule Compression values are: nominal cycle time 

- 129 days, compressed cycle time - 86 days, and compression ratio - 0.67. It is 
estimated that launch delays will occur in 24.5 percent of the flights. 

f. Environmental Impact.- The Space Shuttle uses liquid hydrogen and liquid 
oxygen as propellants, as well as two solid strap-on boosters. Its propellant load 
includes: oxygen - 1361.936 klbm, hydrogen - 227.641 klbm, and solid propellant 

- 2216.0 klbm. Using the given propellant weights, major effluent constituents 
were determined and are shown in Table 3.3.3.1-3. These values are based on 
equilibrium, non- afterburning calculations. 


TABLE 3.3.3.1-3.- EFFLUENT DATA FOR SPACE SHUTTLE 


Exhaust 

Product 

Space Shuttle 
(klbm) 

CO 

574.6 

CO 2 

84.2 

h 2 

102.8 

h 2 o 

1735.4 

HC1 

502.6 

n 2 

208.8 

OH 

0.8 

H 

0.8 

ai 2 o 3 

720.0 
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3.3.3.2 Space Shuttle Evolution 

System Description and Performance Characteristics 

Space Shuttle Evolution looks like and has similar operations to the basic Space 
Shuttle System (section 3.3.3.1) except for specific system upgrades as identified by 
the HTS study team. These improvements include: liquid rocket boosters (LRB), 
electro-mechanical actuators (EMA), light-weight external tanks (LWET), advanced 
thermal protection system (ATPS), light-weight Orbiter (LWO), long-duration 
(90-day) Orbiter (LDO), single I-Load (SIL), SSME limit to 100 percent thrust (SSME 
100 percent), crew ejection seats, and the addition of a reusable cargo vehicle (RCV). 
These 10 items were selected because they are currently being touted as enhance- 
ments to improve Space Shuttle safety, increase performance, reduce turnaround 
time, reduce operational costs, and reduce the number of human flights, while still 
maximizing the use of Space Shuttle's existing infrastructure and its associated fixed 
annual cost. Overall performance increase for the Space Shuttle Evolution Orbiter 
is 13 500 lbs to 160 nmi or 12 000 lbs to SSF. The RCV can place up to 80 000 lbs to 
SSF. A summary of performance for specific altitudes and inclinations is given in 
Table 3.3.3.2-1. 


TABLE 3.3.3.2-1.- SPACE SHUTTLE EVOLUTION PERFORMANCE 

CHARACTERISTICS 


INCLINATION 

(deg) 

APOGEE X PERIGEE 
(nmi) 

PAYLOAD 

(klbs) 



ORBITER 

RCV 

28.5 

160 x 160 

65.6 

88.5 

28.5 

220 x 220 

57.5 

82.0 

28.5 

300 x 300 

48.5 

72.0 

57.0 

160 x 160 

50.1 

83.4 

57.0 

324 x 324 

30.5 

70.0 


a. LRB's.- The LRB's selected for this study are expendable and use four pump-fed 
LO2/RP-I engines per booster. Each booster has engine-out capability from lift- 
off. Switching from the original SRB's to these LRB's provides an additional 
20 klb payload delivery capability. Supporting data for their design was obtained 
from the Martin-Marietta LRB study contract (NAS8-37136). 

b. EMA's.- Converting the Orbiter's control surfaces from hydraulic to electro- 
mechanical actuation offers improved processing time, reduced operating costs. 
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and increased payload performance. These improvements result from 
elimination of the hydrazine APU, APU servicing, and its GSE; hydraulic 
system and its GSE; "SCAPE" suit operations and area clears for actuator tests; 
and potential for hydraulic leaks. Payload performance gains of about 5000 lbs 
are a direct result of eliminating current on-board hardware. Full implemen- 
tation of this improvement is likely only for new Orbiter builds. Candidate 
functions for EMA upgrades include aerosurface control, door actuation, wheel 
deployment, brake actuation, umbilical retraction, and engine gimbal. 

c. LWET - A series of candidate changes in the design of the ET are being 
considered in order to improve performance and reduce weight. The candidates 
include Super Lightweight Ablator substitution, tumble valve deletion, deletion 
of slosh baffle, ET range safety system revision, variable insulation spray pattern, 
margin optimization-LC>2; biaxial yield-LH2 tank; reduced weld land width; 
margin optimization-LH2; biaxial yield-LC>2 tank; TPS LO2 aft dome; LO2 aft 
dome reduction, reduction of LO2 proof pressure, substitution of Al-Li for sheet 
in the intertank area (I/T), I/T margin optimization, machining of I/T TPS, 
two-stage GO2 (Gaseous Oxygen) vent valve, and tolerance weight reduction. 
These changes would provide a cumulative weight savings of about 3000 
pounds, providing nearly a 1 -pound payload increase for each pound of weight 
reduced from the ET. 

d. ATPS.- Five major changes in the TPS are incorporated to provide increased 
safety and reliability due to increased TPS strength and temperature limits and 
reduced operations cost due to decreased maintenance between flights. These 
changes include using Advanced Carbon-Carbon (ACC) for the nose and wing 
leading edges (five times the strength and eight times the modulus of current 
reinforced carbon-carbon). High Thermal Performance (HTP) tiles (higher 
strength, temperature capability, and improved impact resistance), Nextel 
insulation blankets (higher temperature capability than current Advanced 
Flexible Reusable Surface Insulation), using PBI instead of Nomex felt (200- 
300 °F higher temperature capability), and Nextel 312 gap fillers and thermal 
barriers (permit higher mission-use life due to higher temperature capability). 

e. LWO.- This effort, which is also called the Lightweight Aerosurface Structures 
Program, improves reliability and safety, lowers operating costs, and increases 
the Space Shuttle capability by incorporating several modifications: use of 
lighter material (candidates are Al-Li, Graphite/Polyimide,Graphite/ 
Bismaleimide, and ACC) for the primary structure and components such as 
control surfaces, application of developed technologies to additional 
components such as the drag chute structure, and integration of advanced 
materials into Orbiter production and retrofit (i.e., nose cap, chin panel and 
wing leading edge). Besides a reduction of 300-500 lbs per vehicle through 
retrofit, up to 6000 lbs can be eliminated from new orbiters. 
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f. LDO.- The Space Shuttle LDO significantly increases the man-tended SSF crew 
stay time up to a 90-day mission by adding eight tank set pallets containing H2 
and O2, and using some SSF power. Orbiter mission durations of up to 44 days 
are achievable without any SSF provided power. Changes in the Orbiter design 
which will be required for the LDO include high density packing stowage 
approach, autolanding capability to ensure safe return, N2 (storage required to 
meet the crew cabin makeup gas requirements, implementation of long life fuel 
cells, and a number of relatively minor modifications such as docking and 
thermal control. 

g. Single I-Load.- A single season I-load that can be used any time during the year 
is another approach for reducing ascent design effort. The monthly and day-of- 
launch 

I-loads are concerned with absorbing wind and subsystem variations for a given 
launch. These activities result in considerable launch support effort and cost. 

To reduce this effort and complexity, a single season I-Load approach is incor- 
porated. This change affects first stage, flight control I-loads, requires specific 
structural modifications, reduces average performance, and significantly reduces 
launch operations costs by eliminating day-of-launch software updates. 

h. SSME Limit to 100 Percent Thrust.- SSME reliability has been shown to be 
related to operational power level, with lower power levels offering greater 
reliability. 6 By limiting SSME operation to no more than 100 percent thrust 
level versus operating at 104 percent, it is estimated that its single engine 
reliability against mainstage shutdown would be increased from 0.9860 to 0.9947. 
These values compare with 0.9977 used in the HTS study analysis for all liquid 
rocket engines. 

i. Ejection Seats - The ejection seat system was developed as part of the Space 
Shuttle Evolution Phase II Crew Escape Study. The option used for this study is 
capable of ejecting up to eight crew members in about 5 seconds. The oper- 
ational sequence is: (a) blow off the roof structure above the flight deck, (b) eject 
the three crew members seated behind the commander and pilot, (c) blow off 
the section of the flight deck floor, and (d) eject the three middeck crew 
members by pushing them up to and out of the flight deck, followed by the 
commander and pilot. Use of this ejection seat system would provide an 
alternative to the RTLS abort option and would only be used if an RTLS abort 
could not be performed. 

j. RCV- The RCV design is based on the Space Shuttle Orbiter, and, in fact, has 
the same outer mold line as the Orbiter. However, a small pressurized volume 
replaces the Orbiter's crew module. This module provides the environmental 
control for Space Shuttle avionics currently housed in the crew module. In 
addition, specific subsystem items have been relocated forward to improve 
vehicle center of gravity, and hence, return flight characteristics. Operationally, 
it uses all existing Space Shuttle infrastructure. 


3.3-18 


Rev. E 



k. Abort Modes.— The abort modes for the Space Shuttle Evolution will be similar 
to the current Space Shuttle with the exception of the ability of the crew to use 
the ejection seats. This could occur anytime from the pad up to approximately 
the following limits: V=700 fps, H=10 kft, and t=28 seconds from lift off. Ejection 
is not possible between altitudes of 10 kft and 30 kft due to SSME plume heating 
effects with all three SSME's burning. However, there is a 16-second window, 
which opens at 30 kft altitude, where ejection is again possible (altitude range is 
30 - 50 kft, velocity is between 1290 fps and Mach 1.86). If the number one SSME 
is shut down before ejection, then the crew escape option is a continuous 
window from the pad up to an altitude of 50 kft. During descent, the limits for 
using the ejection seats are: V =< Mach 1, and H = 50 000 ft to 300 ft minimum. 
This system can also be used after touchdown to provide an escape option for all 
eight crew members. 

l. Implementation.- The IOC for Space Shuttle Evolution used in this study is 
2000, although all items have a projected availability before the turn of the 
century (Table 3.3.3.2-2). Also, some enhancements would be applicable to all 
flights, while others (e.g., light-weight Orbiter, EMA's) would only be realized as 
new orbiters are built. 

Attribute Values 

System input data related to each attribute, as well as system specific attribute values, 
are discussed below. In most cases, system data is modified by flight rate or cost 
associated with the particular architecture and/or "If being evaluated. However, 
some useful observations can be made at the system attribute level. These will be 
discussed following the presentation of the Space Shuttle evolution data. 

a. Human Safety.- Relevant system data for human safety consists of system 

characteristics that enable the crew to detach or escape from the main body of the 
system during ascent in the event of a mission failure. For Space Shuttle 
Evolution, these include replacement of the SRB's by LRB’s with engine-out 
capability and the addition of ejection seats. The use of LRB's with engine out 
increases the mission success rate and allows the boosters to be shut down and 
expended during the first two minutes of flight. Ejection seats provide more 
coverage (see Abort Modes above) of the mission profile than the slide pole, 
described in section 3.3.3.1, and therefore decreases the probable rate of crew loss 
events. Abort options (described in Section 3.3.3.1) remain and can be used in 
the event of a non-catastrophic SSME or LRB engine failure. Other salient 
features include having the crew module in the same element as the liquid 
engines but over 70 feet ahead of their location, and having the crew module 
parallel to the propellant tank as well as to the liquid rocket boosters. 
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TABLE 3.33.2-2 - SPACE SHUTTLE EVOLUTION ENHANCEMENT PROJECTED 

AVAILABILITY DATES 


SPACE SHUTTLE EVOLUTION 
ENHANCEMENT 

AVAILABLE 

SINGLE I-LOAD 

1994 

100% SSME MAX POWER LEVEL 

1996 

EJECTION SEATS 

1997 

LDO 

1997 

ATPS 

1998 

LWET 

1998 

EMA's 

1999 

LWO 

1999 

LRB’S 

1999 

RCV 

1999 


b. Funding Profile.- Cost information provided to the HTS included the same 
breakdown as for the Space Shuttle system. However, additional costs associated 
with Space Shuttle Evolution development and operations have been included. 
Table 3.33.2-3 presents a summary of this data. 

c. Probability of Mission Success - A system description and flight profile contains 
the required input information for this attribute. In summary. Space Shuttle 
Evolution, with either the Orbiter or RCV in the stack, has 4 liquid propulsion 
stages and 13 liquid engines: 3 SSME's, 4 LRB engines per booster, and 2 OMS 
engines. The system has engine-out capability on each of the LRB from lift off 
and for the Orbiter and RCV per the abort descriptions in section 3.33.1. Its 
mission profile and sequence of events is similar to that shown for Space 
Shuttle in Figure 333.1-1. 

d. Architecture Cost Risk - Two of three subordinate attribute values for ACR, 
Technical Challenge and Program Immaturity, are system dependent. These 
were determined by the NIT through consensus. Since Space Shuttle Evolution 
is a derivative of an operating system and requires development of one new 
flight element (LRB) out of three (SRB, ET, Orbiter), plus a modified version 
(RCV) of an Orbiter, it received relatively high ratings for Technical Challenge 
and Program Immaturity. Specifically, Space Shuttle Evolution was a given a 3 
(Non-Recurring), 2 (Production) and 3 (Operations) as part of its Technical 
Challenge value. These scale ratings, out of a range from 1-10, translated into 
values of 2.78, 1.67, and 2.78, respectively (see ACR discussion in 
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TABLE 3.3.3.2-3.- SPACE SHUTTLE EVOLUTION FUNDING 
PROFILE INPUT DATA 
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Section 3.2.5). On a similar scale from 1-10 for Program Immaturity, Space 
Shuttle Evolution was given a 4, which is a value of 4.64. The third component. 
Number of New Systems, is an architecture-level value. Space Shuttle 
Evolution's contribution to architecture scores for this component of ACR is 
0.93. 
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e. Launch Schedule Confidence.- As in ACR, there are three subordinate attribute 
values for LSC: Schedule Compression, Schedule Margin, and Delays due to 
unscheduled maintenance activities. Schedule Compression and Delays are 
architecture independent, while Schedule Margin is architecture dependent 
since its values are a function of annual flight rates and available facilities and 
Orbiters. Space Shuttle Evolution's Schedule Compression values are: nominal 
cycle time - 87 days, compressed cycle time - 62 days, and compression ratio - 0.73. 
It is estimated that 24 percent of Space Shuttle Evolution's flights, both human 
and RCV, will experience a launch delay. 

f. Environmental Impact.— The Space Shuttle Evolution uses liquid hydrogen and 
liquid oxygen as its main propellants, as well as liquid oxygen and RP-1 in its 
two liquid rocket boosters. Its propellant load includes: oxygen - 2032.936 klbm, 
hydrogen - 227.641 klbm, and RP-1 - 268.700 klbm. Using the given propellant 
weights, major effluent constituents were determined and are shown in 
Table 3.3.3.2-4. These values are based on equilibrium, non-afterburning 
calculations. 


TABLE 3.3.3.2-4 - EFFLUENT DATA FOR SPACE SHUTTLE EVOLUTION 


Exhaust 

Space Shuttle 

Product 

(klbm) 

CO 

625.5 

CO2 

518.8 

h 2 

90.6 

h 2 o 

2286.7 

HC1 

0.0 

n 2 

0.0 

OH 

0.0 

H 

0.0 

Al 2 03 

0.0 
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3.33.3 Assured Crew Return Vehide (ACRV) 

System Description 

The ACRV is currently the subject of a Phase B competition. The material in this 
section is based on a candidate configuration, the Viking-SCRAM, developed in- 
house at JSC. Cost and weight data are data supplied by the ACRV Program. 

As a result of the Space Shuttle stand-down following 51-L, the need for an alternate 
system for returning the SSF crew was identified. A number of studies were 
completed to identify requirements and possible solutions. The conclusion was that 
a dedicated, space-station-based vehide is required to assure the safe return of the 
SSF crew. Three design reference missions for this system are defined as follows: 

• SSF crew return in the event of prolonged Space Shuttle stand-down. 

• Return of ill or injured SSF crew person when Space Shuttle is not available, e.g., 
between normally scheduled Space Shuttle missions to SSF. 

• Emergency evacuation of SSF and subsequent return of crew to Earth. 

These design reference missions define a requirement for an operational mission 
life of up to 24 hours. The crew capadty and the landing mode - vertical or 
horizontal, land or water — are the major open trades to be determined in the Phase 
B study. 

One ACRV is to be delivered to SSF as a payload in the Space Shuttle cargo bay to 
support SSF PMC, and a second is required at EMCC. After berthing at SSF, the 
ACRV will remain on station in a quiescent mode unless called upon for a crew 
return mission. Each ACRV will be returned to Earth, as Space Shuttle cargo, at 
approximately 5-year intervals for refurbishment. Ground processing sites, 
including facilities for refurbishment and pre- and post-flight processing, are also to 
be determined. 

Performance Characteristics 

The Viking-SCRAM ACRV shown in Figure 3.3.3.3-1 is comprised of an 11-ft 
diameter cylindrical crew compartment on a 14.5 ft-diameter Viking heat shield. An 
8-ft diameter service module mounted forward of the heat shield is jettisoned after 
the deboost bum. Berthing at SSF is enabled by a berthing adapter that flares to 
accommodate a small (~36) in ACRV hatch mating at a standard (80 in) SSF hatch. 
The mass summary for the flight segment, including flight support equipment (FSE) 
and airborne support equipment (ASE), is presented in Table 3.3.33-1. Note that, 
with an eight-man capacity, the ACRV cargo capacity is essentially nil. 
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As»ur*d Crtw Return Vthlcl# (ACRV) 
B cr*w, 24 hour mission 



Figure 3.3. 3. 3-1.— Viking-SCRAM ACRV. 
TABLE 3.3.3.3-1- ACRV MASS STATEMENT 


All Masses are in Pounds 


Functional 

Sub-System 

Code 

Crew 

Module 

Service 

Model 

Berthing 

Adapter 

System 

FSE 

& 

ASE 

Meteoroid 

Debris 

Protect 

1 Structure 

1,552 

475 

544 

1,600 

523 

2 Protection 

1,216 

71 




3 Propulsion 

250 

302 




4 Power 

856 

732 




5 Control 

0 





6 Avionics 

990 

48 




7 Environment 

1,817 





8 Other 

989 

52 




9 Growth 

1,150 

252 

82 

240 

79 

Dry Mass 

8,820 

1,932 

625 

1,840 

602 

10 Non-Cargo 

1,820 

56 




11 Cargo 

120 

0 




Inert Mass 

10,760 

1,988 

625 

1,840 

602 

12 Non-Propellant 

373 

0 




13 Propellant 

264 

866 




Gross Mass 

11,397 

2,854 

625 

1,840 

602 
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Attributes Values 


a * Program Costs and Funding Profiles.- ACRV development and acquisition costs 
in Table 3.3.33-2 and the ACRV development profile shown in Table 3.33.3-3 
are based on data obtained from the NASA ACRV program office. A cost 
breakdown is available for the flight segment only, while development and 
acquisition costs are not available for either the ground segment or for the 
mission control segment. The only operations cost available is an estimate of 
$80M for the first 10 years of operation. 

TABLE 3.33.3-2.- ACRV DEVELOPMENT AND ACQUISITION COSTS 


FY92 DOLLARS IN MILLIONS 

INTEGRATION, ASSY, & C.O. 


STRUCT & MECHANISMS 

171.9 

RECOVERY & LANDING 

41.6 

THERMAL PROTECTION 

37.3 

I PROPULSION 

70.8 

POWER (BATTERIES) 

3.0 

ELEC DIST & CONTROL 

49.6 

AVIONICS 

193.2 

ECLSS & PERS PROV 

58.6 

IACO TOTAL: 

626.0 

OFT VEHICLE 

107.0 

TOTAL NON-RECURRING 

733.0 

RECURRING PRODUCTION: 


TWO FLT UNITS @ 107.0 

214.0 

TOTAL DEVEL & ACQ: 

947.0 


b. Probability of Mission Success - The ACRV is passive cargo in the Space Shuttle 
cargo bay for delivery to the SSF. The PMS for this phase is counted as Space 
Shuttle operations, and not as ACRV operations. The PMS for the ACRV crew 
return mission is defined as the probability that the ACRV will successfully 
complete the mission within the limits specified by the System Performance 
Requirements Document (JSC 34000). The availability and performance of the 
ground and mission support segments should not be considered except where 
support functions are necessary to accomplish a safe landing. The mission is 
successfully completed when splashdown or touchdown is within required 
impact acceleration limits (does not include initiation, rescue, or recovery 
functions). Because the ACRV is not manifested as distinct flights, its reliability 
does not contribute to the architecture's PMS score. 

c * Architecture Cost Risk.— The ACRV is a low technology, moderately mature 
study. 
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TABLE 3.3.33-3.- ACRV FUNDING PROFILE 
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d. Operational Flow - As noted previously, the ACRV is carried as a payload in the 
Space Shuttle cargo bay. The processing of this payload is an offline operation as 
far as Space Shuttle processing is concerned. The span available for ACRV 
ground processing (order of years) does not impact processing operations or LSC 
scores. 

e. Environment.— Environmental contamination problems for launch systems are 
addressed in this study. The ACRV does not use any propulsion system within 
the sensible atmosphere, and as a result the only contaminants are those 
produced by a low-thrust-level reaction control system that may be used to 
provide attitude control during the descent phase. 
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3.3.3A Cargo Transfer Function (CTF) 
System Description 


a. History In some of the HTS architectures, cargo delivery to specific 
destinations is required. Using a low cost, expendable launch vehicle (ELV) is 
desirable; however, most ELV's are not equipped with the specific hardware and 
software features that would be required to perform a precision rendezvous. A 
cargo transfer function might be necessary if the cargo was, for example, a 
logistics element for the SSF. Depending on the ELV, the modifications to 
perform this cargo transfer can be minor or significant. The CTF is not so much 
a specific element as a common functionality which the ELV would incorporate 
in an architecture where precision delivery is needed. 

b. Configuration.- The cargo transfer function represents an added capability (and 
cost) associated with precision rendezvous and delivery of untended payloads to 
destinations such as the SSF. Typically, all versions of CTF include features 
such as payload support and attachment structure, avionics, power, 
communications provisions, attitude control thrusters and tankage, and 
guidance software. In this study, the CTF is related to evolutionary versions of 
the Delta, Atlas, and Titan launch vehicles. The CTF will correspond to 
different designs depending on the launch vehicle, but all the concepts must 
conform to the following mission groundrules and operational requirements 
shown in Table 3.3.3.4-1. 

c. Abort Modes.- The CTF is never used with human elements and has no specific 
abort modes. 

d. Facilities - The CTF facilities will be very similar to existing upper stage facilities 
at the U.S. Eastern Test Range sites. In many cases, only minor modifications 
may be required to use existing facilities for future operations at KSC or Cape 
Canaveral Air Force Station (CCAFS). Each carrier booster element section 
contains a description of the facilities requirement assumptions for the HTS 
study. Since most CTF designs use bipropellant OMS fuels and hydrazine RCS 
fuel, existing tank loading and settling facilities at CCAFS will need to be 
retained. 

e. Operational Flow - The operational flows are very similar to the NLS Cargo 
Transfer Vehicle and Advanced Upper Stage flows, except the flow time lengths 
may be different due to smaller vehicle size and different subsystem conceptual 
designs. The upper stage flow is considered parallel to the booster flow and 
doesn't result in any schedule drivers. 
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TABLE 3.3.3.4-1.- CTF GROUNDRULES, ASSUMPTIONS, 
AND TECHNICAL REQUIREMENTS 


• SSF is in 220 nmi circular orbit 

• CTF element(s) is (are) physically attached to payload, but supplies no 
services to the payload, nor does it receive services from SSF or other 
destination infrastructure 

• Payload c.g. is on longitudinal centerline 

• Active mission time is 25 hours 

• 14 days on-orbit survival time 

• MRMS (robotic arm) is the capture mechanism at SSF (two grapple 
fixtures on the CTF are required) 

• No on-orbit maintenance of CTF 

• CTF has sufficient GN&C capability to target payload to an envelop 
(typically 10 foot in diameter by 10 foot long volume) and stabilize 
attitude (nominally 0.05 deg/sec in x,y,z) 

• Automated rendezvous 

• Range rate and angle rate sensor 

• GPS is used for navigation 

• Person-in-the-loop proximity operations at SSF 

• Ku band communications 

• TV to SSF for final 3000 feet of approach 

• Telemetry (32 Kbps) through TDRSS 

• 6 DOF control 


Performance Characteristics 


The CTF itself has no performance capability, rather it is a feature that is added to a 
launch vehicle and is specific to that vehicle (see Figure 3.3.3.4-1 for Atlas example). 
Although there would be additional mass for the CTF, with a resulting reduction in 
payload capacity for a given launch vehicle, this effect was considered secondary. 


Attribute Values 


a. Funding Profile Summary - The CTF estimates were developed by the three 
NIT member sources responsible for the parent launch system inputs. Each 
industry representative defined a new conceptual design and weight statement 
(no known current bus stages meet the requirements for this function) for cost 
estimating. Each NIT member assigned a CTF estimating task submitted a 
parametric cost estimate (in constant-year 1992 dollars excluding NASA 
program factors) for their respective CTF space flight element. 
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Figure 333.4-1- Atlas example. 


A summary of the cost estimates for CTF are shown in Table 33.3.4-3. Appendix 2.4 
contains the cost estimate inputs sheets for each respective CTF conceptual design. 


TABLE 33.3.4-2.- CTF COST SUMMARY 


| (1992 Dollars in Millions) j 


Atlas 

Delta 

Titan 


CTF Stage 

CTF Stage 

CTF Stage 

Development: 
C/D Phase 
Facilities 

$243 

$243 

$114 

Total - 

243 

243 

114 

Production: 
Theo. 1st Unit 

16 

16 

87 

Supt./ Equip. Set 

11 

11 

10 

Oper. and Support: 
Variable Cost 

XX 

XX 

XX 

Fixed Annual 

X 

X 

X 
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b. Probability of Mission Success - The mission of the CTF begins after the CTF or 
payload has been inserted into orbit. By definition, mission success only 
considers flight phases up to orbital insertion. The CTF, therefore, has no 
contribution to the overall PMS as it is defined in this study. 

c. Human Safety.- The CTF is used in conjunction with untended missions and 
therefore does not contribute to any safety score. 

d. Architecture Cost Risk.- The CTF designs for the three versions were considered 
similar to the point where one set of risk scores were adequate. For the non- 
recurring portion of the Technical Challenge subattribute, a score of 4 reflects the 
NIT view that the CTF is within the state-of-the-art. A Production score of 2 and 
an Operations score of 3 are indicative of the small size and existing processes 
required to produce a CTF. The Program Immaturity factor was a 6, which 
reflects the lack of detail design at this point. 

e. Launch Schedule Confidence.- The CTF operates in conjunction with other 
systems and does not have its own score for LSC. 

f. Environment.- The CTF involves operation of elements outside the sensible 
atmosphere and does not contribute to the environment attribute score as it is 
defined in this study. 


3.3-31 


Rev. E 



3.33.5 Delta H 


System Description 

a. History - The Delta II is the newest, most powerful version of the Delta series of 
launch vehicles. Originally developed by and for NASA/Goddard Spaceflight 
Center, the Delta, using components from the USAF's Thor IRBM program and 
the Navy's Vanguard launch vehicle program, was first launched on May 13, 
1960. Through mid-1992 there have been 196 successful launches out of 206 
attempts, demonstrating a reliability of greater than 94 percent. 

b. Configuration(s).- The current 7000 series booster configuration, the most 
advanced to date, was developed as the result of being selected by the USAF, 
during the Medium Launch Vehicle (MLV-1) competition, to launch the Global 
Positioning System (GPS). The first flight of this currently available Delta II 
occured on November 26, 1990. The characteristics of the Delta II launch vehicle 
are given in Table 3.33.5-1. Two-stage (7920) and three-stage (7925) versions are 
operational at this time. Two different payload fairing (PLF) sizes are offered, 9.5 
and 10 ft diameter. The overall vehicle is shown with each of these PLF's in 
Figure 333.5-1 for the three stage configuration. The overall dimensions of the 
two stage are the same. 


TABLE 33.3.5-1.- DELTA U VEHICLE CHARACTERISTICS 



Strap-On-Solids 

First Stage 

Second Stage 

Third Stage 

Length (ft) 

42.5 

85.6 

19.6 

6.7 

Diameter (ft) 

3.3 

8 

8 

4.1 

Total weight Oh) 

28,618 ea (GL)* 

224,239 

15,394 

4,721 


28,800 ea(AL)** 




Engine/motor 

GEM 

RS-27/C 

AJ10-118K 

StaM8B 

Manufacture 

Hercules 

Rocketdyne 

Aerojet 

MTI 

Quantity 

6 (GL)* + 3 (AL)** 

1 

1 

1 

Propellants 

Solid 

LOX/RP-1 

N 2 O 4 /A-50 

Solid 

Propellant weight 0b) 

25,800 ea 

211,147 

13,367 

4,430 

Thrust (lb) - SL 

98,870 ea 

201,000 

- 

- 

-VAC 

110,820 ea 

237,000 

9,645 

15,100 

Isp (sec) - SL 

245.7 

255.6 

- 

- 

-VAC 

273.8 

301.8 

319.4 

292.6 

Bum time (sec) 

63 

265.4 

439.7*** 

87.1 

Expansion ratio 

10.65:1 

12:1 

65 

54.8 

♦Ground lit 
♦♦Air lit 
♦♦♦Incl restarts 
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Figure 3.3.3.5-1- Delta II 7925 configurations. 


c Operations.- Launch Operations: Delta vehicles are launched from Launch 
Complex 17 (LC-17) at CCAFS. LC-17 contains two active pads, 17A and 17B. 

The two pads can be used for simultaneous build up of two vehicles. The Delta 
launch site operations flow and typical (nominal) launch ops timeline are 
shown in Figure 3.3.3.5-2. Nominal operations can accommodate up to 
12 launches per year from CCAFC. 

West coast launches are from Space Launch Complex 2 West (SLC-2w) at 
Vandenberg Air force Base (VAFB). Vehicle and payload processing operations 
are performed at Building 836 in South Vandenberg and at the launch complex. 
The Delta launch vehicle elements are delivered to VAFB from Huntington 
Beach, California, where they have gone through the equivalent of the CCAFS 
Area 57 Delta Mission Checkout (DMCO). SLC-2w activities are similar to the 
LC-17 described in Figure 3.3.3.5-2. 

Flight Operations .- Typical two- and three-stage mission profiles are shown in 
Figure 3.3.3.5-3. Details of a three-stage (7925) vehicle geosynchronous transfer 
orbit (GTO) mission profile are given in Figure 3.3.3.5-4. 
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Figure 3.3.3.5-2- Delta processing (ETR). 




Figure 3.3.3.5-3 Typical mission profiles. 
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Event 

V, 
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(g's) 

Liftoff 
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1.33 

6 SRM Burnout 

3258 

0.54 

MECO 

19.962 

5.74 

SECO 1 

25,645 

0.66 

SECO It 

27,106 

0.75 

Stage III Bumoul 

33.630 

3.56 


Eastern launch site, flight azimuth 95 deg; maximum capability to 28.7-deg inclined GTO 
1 00- nmi perigee. 


Figure 3.3.3.5-4.- Typical Delta II 7925 mission profile — GTO mission. 


Performance Characteristics 

a. GLOW.- The gross lift-off weight of the Delta n, not including payload, is given 
in Table 3.3.3.5-2 for both the two-stage (7920) and three-stage (7925) vehicles. 

b. Cargo Envelope.- Details pertaining to the payload fairings and the available 
envelopes can be seen in Figure 3.3.3.5-5. Information for the two-stage and 
three-stage vehicles is shown for both the 9.5- and 10-ft diameter fairings. 

c. Cargo Capacity- The performance of the Delta II is shown in Table 3.3.3.5-3 as a 
function of orbital destination or orbital energy level, in the case of 
interplanetary missions. 
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TABLE 3.3.3.5-2.- VEHICLE GROSS WEIGHT 
(DOES NOT INCLUDE PAYLOAD) 


Weight Lbs. 


Solids 

6 Ground Lit 

2 Stg (7920) 

3 Stg (7925) 

2 Air Lit 

171,696 

171,696 

First Stage 

86,400 

86,400 

Second Stage 

224,239 

224,239 

Third Stage 

15,394 

15,394 

subtotal; 

NA 

4.721 

Fairing(s) 

497,729 

9.5 ft 10 ft 

502,450 

9.5 ft 10 ft 

Total(s): 

1.850 2.200 

1.850 2.200 


499,579 499,929 

504,300 504,650 


g] UMMM <m*iW tmkym MpfraMn pi*"* 
y/A fwnngfi H op* 



ife — 


1 






TABLE 3.33.5-3.- DELTA II PERFORMANCE DATA 


Mass to Orbit (lbs) 

28.5 degrees, 160 nm circular 

10,900 

2 stg 

28.5 degrees, 220 nm circular 

10300 

2 stg 

57.0 degrees, 160 nm circular 

8.800 

2 stg 

98.3 degrees, 450 nm circular * 

7,000 

2 stg 

GTO 

4,010 

3 stg 

Interplanetary 

(28.7 degree 100 nm perigee altitude) 

C3=0 Km 2 / Sec 2 

C3=25 

C3=50 

2,830 

1,700 

1,030 

3 stg 

* WTR launch, all others ETR 




Attribute Values 

a. Funding Profile Summary.- The data in Table 3.33.5-4 was provided as input 
for the calculation of the funding profile attribute. 


TABLE 333.5-4.- FUNDING PROFILE COST INPUTS (MILLIONS OF $) 


NON-RECURRING: 

RDT&E $0 

N/R $0 

Production $0 


RECURRING 

(Includes; Prod, Launch Ops, Flight Ops, Prog Mgt&Sup) 
Fixed Cost/Flight $140 Fixed Cost/Flight $29 

~~~ ~3 ~2 4 Yearof 

Spread Factors Flight 

14% 48% 8% 32% 


b. Probability of Mission Success - The flight profile shown previously in Figure 
333.5-4 was used to derive the PMS reliability tree for the Delta vehicle. 

Vehicle characteristics used in the calculation included the use of 2 liquid rocket 
engines (first and second stages), 10 solid rocket motors (9 for thrust 
augmentation and 1 for third stage), and 3 liquid propulsion stages (first stage 
and the equivalent of 2 for second stage, due to restart of second stage). Because 
Delta is an existing vehicle with a launch history, the actual flight reliability of 
94.1 percent (175 successes out of 186 attempts - 1964 through 1992) can be 
compared to the PMS calculated value of 93.2 percent. 
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c. Human Safety - Not applicable. 

d. Architecture Cost Risk - Two of the three subattributes were based on system 
values, or scores. For the Delta vehicle, an existing vehicle, the NIT concensus 
scores for those subattributes, technical confidence, and program maturity, were 
both 1.0. 

e. Launch Schedule Confidence - As with ACR, two of the three subattributes 
were based on system values, or scores. One of these, schedule compression, 
was calculated based on the operations data given in section 3.3.3.5.I. The value 
of schedule compression was calculated to be 53 days saved from a nominal 101 
day processing time, or 0.52. The other value, percent of flights with delays, was 
calculated to be 7.59 percent. Both of these calculated values, along with the 
schedule margin subattribute, were subsequently used with architecture- 
particular flight rate data to rollup the architecture schedule confidence attribute 
and value. Historically, six percent to nine percent of Delta flights have been 
delayed beyond the launch window due to hardware (six percent due to vehicle 
hardware and three percent due to support hardware). 

f. Environment.- The Delta vehicle first stage has an RP-1 /liquid oxygen (LOX) 
propellant load of 211 147 lbm, the second stage has 13 367 lbm of N 2 04/A-50. In 
addition, nine solid strap-ons with 229 308 total lbm of propellant are used 
during the boost phase. Although the Delta utilizes a third stage on some 
flights, its use is outside the atmosphere and therefore does not contribute to the 
effluent total. 

Using the given propellant weights, the major effluent constituents (in klbs) are 
shown in Table 3.3.3.5-5. These values are based on equilibrium, non- 
afterburning calculations. 


TABLE 3.3.3.5-5- EFFLUENT DATA FOR DELTA U 


Exhaust 

Delta II 

Product 

Effluents 

CO 1 

125.2 

CO 2 

76.6 

h 2 

6.6 

h 2 o 

70.4 

HC1 

31.4 

n 2 

17.8 

OH 

0.0 

H 

0.0 

Al 2 03 

45.0 
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3.3.3.6 Atlas Launch Vehicle Family 
System Description 


a. History.- The current Atlas launch vehicle family has steadily evolved from the 
1950's Atlas Intercontinental Ballistic Missile (ICBM) program. Since then over 
500 Atlas launch vehicles have been flown in various configurations from both 
east and west coast launch sites. The current family uses the same basic 1.5 stage 
core vehicle as the early concepts, but also incorporates a state of the art 
cryogenic (LH 2 /LOX) upper stage. Centaur. 

b. Configurations.- Although various configurations of Atlas will be flown 
throughout the next several years, the Atlas HAS configuration is being used as 
the representative vehicle in the mission capture analyses from 1998 to 2020 (the 
NASA Mixed Fleet Manifest is used from 1992 to 1997). Figure 3.3.3.6-1 shows 
the Atlas HAS relative to the I, II, HA, and two evolutionary options. An 
additional configuration, the Atlas E, has been flown frequently over the last 
several years (not shown in the figure). This configuration is not used in 
architectures beyond that specified in the Mixed Fleet Manifest (1997 and 
earlier). 



•LARGE (14 FT) 
FAIRING 
• NEW DATA 
ACQUISITION 
SYSTEM 


•LENGTHEN ED ATLAS 

• LENGTHENED 
CENTAUR 

• INCREASED ATLAS 
ENGINE THRUST 

•STATE OF THE ART 
CENTAUR AVIONICS 

• FIXED FOAM CENTAUR 
TANK INSULATION 


• ADDED FOUR SOLID • ATLAS IIAS WITH • REPLACED SOLID 

ROCKET MOTORS ADAPTOR MODIFIED ROCKET MOTORS 

(CASTOR IVAs) TO PROVIDE CARGO WITH LARGER SRMS 

TRANSFER FUNCTION • REPLACED RL-IOs 
WITH SINGLE 
ENGINE ON CENTAUF 
• PRELAUNCH 
PROCESSING 
ENHANCEMENTS 


Figure 3.3.3.6-1- Atlas launch vehicle family. 


One evolutionary option of the Atlas IIAS includes a modification of the 
payload adaptor to provide the CTF. The CTF enables a system to perform 
rendezvous and proximity operations (including docking or berthing) with SSF 
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or other LEO node destinations. The modifications to provide the CTF primarily 
consist of relocating some Centaur equipment (e.g. avionics) and the addition of 
off-the-shelf equipment needed for the proximity operations near SSF (e.g., 
sensors and thrusters). In addition, the Centaur will require some structural 
uprating to handle the larger LEO payloads. Figure 3.33.6-2 depicts the 
configuration and composition of the CTF. 
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RCS THRUSTERS 
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Figure 3.33.6-2.- Atlas /CTF configuration. 


Another evolutionary option involves reliability, prelaunch processing, per- 
formance, and cost enhancements to the Atlas IIAS. As seen in Figure 333.6-1, 
this evolutionary option involves modification of the Centaur for a single 
upgraded RL-10, larger SRM’s, a Centaur Processing Facility (CPF), and other 
enhancements to prelaunch processing. 

c. Facilities.- The east coast facilities (CCAFS) used by the Atlas family primarily 
consist of a booster processing facility (Hangar J), SRM storage facilities, an off- 
line payload processing facility, and two launch pads (Pad 36A/B). A majority of 
the integration and checkout between the booster, upper stage, solids, and 
payload is done on the pad. 

The west coast facilities are currently only equipped to handle Atlas E class 
vehicles (i.e., no Centaur). The mission capture analyses did not include any 
Atlas launches from the west coast beyond those specified in the NASA Mixed 
Fleet Manifest. 
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The Atlas with the CTF does not require construction of additional facilities, 
however, minimal modifications to the existing support equipment are 
anticipated and are included in the nonrecurring costs. 

The Atlas evolution option includes the construction of a new CPF at the 
CCAFS for off-pad checkout. This additional facility, along with some other 
proposed or planned prelaunch processing enhancements, would reduce the 
time between consecutive launches to 38 days. The Titan evolution concept also 
benefits from the Centaur off-line processing. 

d. Operational Flow.- The Atlas booster/ sustainer and Centaur upper stage are 
delivered to the booster processing facility for inspection and pre-integration 
processing (3 and 6 days respectively). The Atlas is then transported to the pad 
and erected (2 days). Once the Centaur has completed its receiving inspection 
and preliminary checkouts it is moved to the pad and mated on top of the Atlas 
(5 days). At this point a series of Atlas /Centaur/Ground System interface checks 
and system tests including SIMFLIGHT (electronics and software) and Wet Dress 
Rehearsal (fluids and cryogens) are performed (24 days). Next, the solids are 
mated to the stack (4 days). At this point the encapsulated payload is delivered to 
the pad and integrated onto the launch vehicle (2 days). A final certification is 
performed on the entire stack after which the launch preparations and 
countdown occur (5 days). 

The processing flow for the Atlas HAS is shown in Figure 3.3.3.6-3. The dwell 
times in each facility are also noted. The assumed shift schedule for Atlas 
processing is 5 days a week with one 8-hour shift. However, the last 5 days are 
around-the-clock operations at a 1.75 shift equivalent. With pad refurbishment 
and booster processing run in series, the minimum time between consecutive 
launches is 52 days. This allows a theoretical maximum launch rate of 14 flights 
per year (2*365/52) for 2 pads. Under nominal operating conditions (i.e. 365 days, 
less weekends and holidays) up to 10 launches per year are achievable. 

Since most of the CTF subsystems are simply relocated from the Centaur to the 
payload adaptor, the processing flow for Atlas/ CTF will be the same as the Atlas 
HAS (Figure 3.3.3.6-3). 

The processing flow for the Atlas evolution is shown in Figure 3.3.3.6-4. The 
CPF allows Centaur upper stages to be processed off-line for both Atlas and Titan 
missions. The booster on-pad operations are reduced through a number of 
planned and proposed enhancements to the vehicle and the ground segment. 
These include avionic and other vehicle subsystem upgrades, ground support 
equipment and launch control system enhancements, and optimization of 
manufacturing and launch operations. 
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Figure 33.3.6-3 - Atlas HAS processing flow. 



Figure 3.33.6-4 - Atlas evolution processing flow. 


33-42 


Rev. E 






















Performance Characteristics 


The Atlas performance characteristics for the three configurations being used in this 
study are shown in Table 3.3.3.6-1. The Atlas/CTF is only used for SSF deliveries; 
therefore, the table only shows performance to 220x220 nmi, 28.5°. The Atlas 
evolution concept has been estimated at the same gross lift-off weight (GLOW) as 
the current vehicle because most enhancements are in the ground processing area, 
and those changes that result in mass differences tend to be offsetting (to the extent 
that they have been analyzed). 


TABLE 3.3.3.6-1.- ATLAS LAUNCH VEHICLE PERFORMANCE 



Atlas HAS 

Atlas/CTF 

Atlas Evol. 

GLOW (lbs) 

515,900 

523,000 

515,900 

Press. Volume (ft3) 

0 

0 

0 

Cargo Envelop (lxd) 

20x13.4 

20x13.4 

20x13.4 

Cargo Capacity (lbs): 




160 nmi circ, 28.5° 

17,600 

n/a 


220 nmi circ, 28.5° 


16,000 

18,800 

300 nmi circ, 28.5° 

15,700 

n/a 


30x220 nmi, 28.5° 


n/a 

22,000 

GTO, 26° 

7,700 

n/a 

10,000 

Return Capacity (lbs) 

0 

0 

0 

Crew Capability (#) 

0 

0 

0 

Launch Site Limits 

East Coast 

East Coast 

East Coast 


Attribute Values 

a. Funding Profile Summary.- The Atlas costs for the three configurations being 
used in this study are shown in Table 3.3.3.6-2. Because many of the cost 
numbers are architecture dependent, the following numbers have been 
calculated based upon several flight rates. The identified launch facility costs are 
incorporated only if required by the architecture and "If" Scenario (i.e. flight 
rates exceed capacity of current facilities). The CPF is only used in Architecture 2 
and is used by both Titan/ Centaur and Atlas/ Centaur. 

The Atlas/CTF development schedule is shown in Figure 3.3.3.6-5 as a function 
of years from the start of Pre-Phase A studies of the system requirements. The 
program follows the standard development stages and ends with an initial 
operating capability in the seventh year. 
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TABLE 3.3.3.6-2- ATLAS LAUNCH VEHICLE COSTS 


All Values in M92$ 

Atlas IIAS 

Atlas /CTF 

Atlas Evol. 

DDT&E 

0 

218 

100 

N/RProd 

IHHOI 

24 1 

0 

P3I 




Facilities (if required): 




Pad - ETR 

381 

381 1 

381 

SLC-WTR 

476 

476 

476 

Cent Proc Fac - ETR 



150 


120 

132 

108 

4/vr 

93 

101 

86 

6/vr 

85 

91 

78 

8/vr 

80 

85 

74 


78 

83 

72 

1 mu 

76 


r 71 



PROGRAM YEARS 




PROGRAM MILESTONES 

1 

2 

3 

D 

5 

6 


8 

ATLAS CTF PROGRAM 
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f?h 
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Figure 3.3.3.6-5.- Atlas /CTF development schedule. 
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b. Probability of Mission Success - The PMS estimate for Atlas IIAS is based upon 
the use of a 3-liquid engine booster/ sustainer, 2-engine/ 2-burn liquid upper 
stage, and four monolithic solids. The reliability tree for Atlas HAS PMS is 
included in the Technical Appendix. This reliability tree, the basic configuration, 
and the historical reliability estimates for characterized subsystems results in an 
Atlas IIAS PMS of 0.9326. Refer to the PMS section of this report to further 
understand the measurement technique being applied (section 3.2.4). 

For the Atlas /CTF, the CTF performs only on-orbit maneuvering, which is not 
being accounted for in the current definition of PMS. Thus the Atlas HAS and 
Atlas /CTF have the same PMS value (0.9326). 

The Atlas evolution concept employs a single-engine Centaur and therefore has 
a different upper stage impact upon the PMS attribute. The PMS measurement 
for Atlas evolution is 0.9369. 

c. Human Safety.- The Atlas does not carry human vehicles in the architectures 
currently being examined in this study and therefore does not have a 
corresponding safety score. 

d. Architecture Cost Risk.-The Atlas is an existing system which is currently 
performing missions and therefore has little to no risk. In the Technical 
Challenge subattribute the Atlas was judged with having no risk in all three 
program categories (i.e., nonrecurring, production, and operations). The Atlas 
was also judged to be a mature system and therefore warranting the lowest 
Program Immaturity score. The Atlas evolution was judged to have a small risk 
in the non-recurring development and to be less mature than the current flight 
configuration. The Atlas/CTF was judged to have a moderate amount of risk 
because it has yet to enter Pre-Phase A development. Table 3.3.3.6-3 presents the 
Atlas family contributions to the ACR. 


TABLE 3 . 33 . 6-3 - ATLAS FAMILY RISK SCORES 


Atlas Risk 
Attribute 

Technical Challenge Sub-Attribute 

Prgm. Immaturity 
Sub-Attribute 

Non-Recurring 

Production 

Operations 

Atlas 

1 

1 

1 

1 

Atlas/CTF 

4 

2 

3 

6 

Atlas Evolution 

2 

1 

1 

3 


e. Launch Schedule Confidence.- As with ACR, two of the three subattributes for 
LSC were based on system values or scores. One of these, schedule compression, 
was calculated based on the operations data given previously in this section; its 
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value represents the ratio of nominal processing time to the shortest processing 
time (maximum compression of the critical path). The nominal processing time 
is determined in calendar days (i.e., includes weekends). The other subattribute, 
percent of flights with delays, was calculated based upon UMA's for the system 
(see section 3.2.6). Table 3.3.3.14-4 shows the above two subattribute scores for the 
Atlas launch vehicle family. Both of the subattribute values were subsequently 
used with architecture-particular, flight-rate data to roll-up the architecture level 
values. The schedule margin subattribute score is architecture-specific and is 
described in Sections 3.3.5 through 3.3.11. 


TABLE 3.3.3.6-4.- SCHEDULE CONFIDENCE SUBATTRIBUTE 
SCORES FOR THE ATLAS LAUNCH VEHICLE FAMILY 


Atlas 

Schedule 

Confidence 

Attribute 

Schedule Compression SubAttribute 

% Flights With 
Delay 

SubAttribute 

Nominal 
Processing 
Time (Days) 

Compressed 
Processing 
Time (Days) 

Ratio: 

Nominal to 
Compressed 

Atlas 

66 

32 

0.485 

5.37 

Atias/CTF 

66 

32 

0.485 

5.37 

Atlas Evolution 

39 

19 

0.487 

5.37 


f. Environment.- The Atlas booster uses RP-1 and liquid oxygen as propellants. 
The HAS has a sustainer /booster propellant load of 344.5 klbm, solid rocket 
motor propellant mass of 22.3 klbm, and an upper stage propellant load of 37 
klbm (liquid hydrogen and liquid oxygen). However, the upper stage operates 
outside the sensible atmosphere and does not contribute to the environment 
score as defined in this study. 

Using the given propellant weights, the major effluent constituents (in klbs) are 
shown in Table 3.3.3.6-5. These values (klbm) are from the October 1991 ALAA 
Workshop and Report on "Atmospheric Effects of Chemical Rocket 
Propulsion". 7 They are based upon equilibrium, non-afterburning calculations. 
Recognizing that this is a low- weigh ted attribute and that Atlas does not fly 
extensively in most architectures (most of its missions are commercial, which 
are not being considered in the current "If" Scenarios) it was assumed that 
Atlas /CTF and Atlas evolution effluents were the same as the Atlas HAS. The 
environmental effects of larger solids for the Atlas evolution concept will be 
assessed in later efforts. 
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TABLE 3.3.3.6-5.- ATLAS IIAS EFFLUENTS PER LAUNCH 


Exhaust 

Characteristics 

Atlas HAS 

Atlas/CTF 

Atlas Evol. 

CO 2 

128.8 

128.8 

128.8 

GO? 

95.8 

95.8 

95.8 

Hz 

8.2 

8.2 

8.2 

H 2 O 

146.2 

146.2 

146.2 

HC1 

14.0 

14.0 

14.0 

N 

5.6 

5.6 

^ 5.6 

OH 1 

0.0 

0.0 

0.0 

H 

0.0 

0.0 

0.0 

Al?03 

20.0 

20.0 

20.0 
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33 . 3.7 Titan Family 


This family indudes the Titan II, Titan HI, and Titan IV basic launch vehicles, as 
well as various upgrades and improved versions postulated for future develop- 
ment. 

System Description 

All Titan launch vehicles currently utilize a 10-ft diameter core containing storable 
hypergolic propellants (Aerozine-50 and nitrogen tetroxide (NTO), with length 
stretched according to needed lift capability. Independent propellant tanks (oxidizer 
on top) are supported by aluminum monocoque construction. Two LR-87 gas 
generator cycle engines with a shared-feed system, but separate turbopumps, power 
the first stage. The second stage is of the same diameter and utilizes the same 
propellants, but employs one LR-91 engine (similar to the lst-stage engines, but with 
lower thrust - 100 klbf vs. about 500 klbf), a higher expansion ratio nozzle, and 
higher vacuum specific impulse. Hydraulic systems are incorporated for core 
engine gimbaling. Power is obtained from Ag-Zn batteries; no APU's are required. 
Current versions of Titan allow for only one bum of the second stage. With the 
addition of a "start-kit", the second stage could be restarted, after a coast to apogee, 
for greater insertion into circular orbit capability (this option is not currently 
incorporated in any of the HTS architectures due to the reliability penalty assessed by 
the HTS methodology). 

TABLE 3.3.3.7-1.- TITAN FAMILY CHARACTERISTICS 



No. and Type of Engines (# Engine Out)** 



Stage 1 


■K&E9SS m 

Cargo Only: 

Titan II G No Upper 



1L 


Stage (NUS) 

- 

2L 

— 

Titan III/Cmrl Titan 

2S 

2L 

1 L + RS 

— 

Titan IV (NUS) 

2S 

2L 

1 L + RS 

— 

Titan IV (Centaur) 

2S 

2L 

1L 

2L + 2RS 

Titan IV (CTF/LRV) 

2 S 

2L 

1L 

4L 

Titan Evol (LDC) 

— 

2L + 2S 

1L 

— 

Titan Evol/Centaur 

- 

2L + 2S 

1L 

1 L + 2RS 

Crew Carriers: 




4 L (l-out) 

•HR Titan IIS (RUPC) 

— 

2 L + 10 GEM 

1L 

•HR Titan IV (RPC) 

12 L (1-out) 

2L 

1L 

3 L (l-out) 


* Postulated designs (subject to change) 

•♦Unless indicated, no engine-out capability 

L=liquid engine; S=segmented solids (large); GEM=small monolithic solids; 
RS=Restart 


3.3-48 


Rev. E 





Currently, the Titan III and IV have two large strap-on solid rocket motors; the Titan 
IIS includes 4 to 10 solid strap-ons. Whereas the solids on Titan n are small, 
monolithic grains, the two strap-ons for T-ffl and T-IV are segmented solid rocket 
motors - 5.5 segments for T-III, 7 segments for the currently operational T-IV, and 
the more advanced 3-segment composite case version known as the SRMU (solid 
rocket motor upgrade), planned to be available for the T-IV in 1993. For evolution 
(growth) of Titan, used in Architecture 2, additional vehicle development is 
required. The implementation schedule for this development is shown in Figure 
3.3.3.7-1. The "Titan IV Evolution" launch vehicle defined for this study is a 
potential future development, featuring a large diameter core (14 ft) to achieve 
higher payload lift capability. 

The human-rated (HR) version of the Titan II (HR Titan US) employs 10 of the 
small solids. The HR Titan IV concept incorporates the normal core, but with LRB's 
in place of solids, in order to provide the capability for emergency shut down. Each 
LRB is powered by six (or five) engines, with one engine-out and on-pad checkout 
capabilities. 

Reusable personnel carrier (RPC) and reusable ultralight personnel carrier (RUPC) 
crew cabs are carried by the HR Titan IV and HR Titan IIS, respectively (see 
Architectures 14 and 17). The RPC and RUPC are self-contained vehicles with 
integral orbital propulsion stages, launch escape systems, and all necessary thermal 
systems to survive ascent heating without the benefit of a separate, external shroud, 
as is the norm for cargo-only payloads. 

Performance Summary 

Titan vehicle lift capabilities are given in Table 3.3.3.7-2. Payload shrouds vary, 
ranging from 10-ft diameter (by 20, 25, or 30-ft tall) for Titan II, 13-ft diameter (by 35-ft 
height) for Titan HI, and up to 16.7-ft diameter (by 56 to 86-ft height) for Titan IV. 

TABLE 3.3.3.7-2- TITAN PERFORMANCE CAPABILITIES 


J Payload to Orbit (klbm) 

Orbit Type 

IIS 

m 

IV 

IV Ev* 

IV LRB* 

1. Standard (80x95 @ 28.5° 

14.4 

31.6 

45.3 

64.3 


2. Circ., 28.5°, 160 n. mi. 

12.0 

27.1 

44.7 

62.1 

56.4 

3. Circ., 28.5°, 220 n.mi. 

10.1 

25.5 

43.5 

60.0 

55.6 

4. Circ., 28.5° , 300 n.mi. 

8.6 

17.2 

41.3 

58.2 

53.1 

5. SSF Transfer (80x220) 

12.0 

31.0 

47.0 

62.0 

49.0 

6. Circ., 57° , 160 n.mi. 

11.1 

17.4 

42.6 

59.2 

54.8 

7. Circ., polar, 150 n.mi. 


18.5 

36.3 

51.9 

47.3 

8. Circ., 98.7° , 445 n.mi. 


2.8 

7.0 

9.5 

8.9 

9. GTO, (100x19330) 


8.4 

25.4+ 

35.3+ 

-.- 


* Postulated designs (subject to change) 
t Includes Centaur Class Upper stage (or Centaur Evol for T-IV Ev). 
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Figure 3 . 33 . 7-1 .- Titan IV growth vehicle implementation schedule. 
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Attribute Values 


Complete data on Attribute data for each of the Titan LV's in this family are 
provided in the Appendices. In the following sections, noteworthy characteristics or 
unique features of the Titan design are identified for each Attribute. 

a. Funding Profile.- Titan system cost information used in the funding profile 
summary calculation is shown in Table 3 3.3.7-3. 


TABLE 3.3.3.7-3.- TITAN SYSTEM COST INFORMATION 


Millions of '92$ - No Wraps j 


RUPC 

T-IIS 

T-IV 

T-IV 

T-IV 

T-IV 

T-IV 




HR 

NUS 

w/ 

w/ 

NUS 

HR w/ 

E 1 



for 

RUPC 

ETR 

CTF 

CTF 

Evol'n 

RPC 

H 

DDTE 

1,425 

0 

0 

0 

102 

0 

298 

0 

N/R Prod. 

145 

0 

0 

0 

12 

0 

0 

0 

P 3 ! 

— 

518 

0 

0 

0 

403 

518 ; 

0 

Facilities: 

Pad-ETR 


300 

477 

477 

477 

477 

477 


SLC-WTR 

— 


(596) 

(596) 

— 

— 

— 


VIB-Hi Bay 

— 

— 

155 

155 

155 

155 

155 


SMAB 

— 

— 

144 

144 

144 

144 

144 


RUPC Test 

3 

— 

— 

— 

— 




Cost/Flight @ 
2/yr 

64 

102 

266 


344 

303 

(1)348 

38 

4/yr 

51 

82 

213 



243 

(2) 279 

30 

6/yr 

45 

72 

187 

234 


213 

(3) 245 


8/yr 

41 

66 

170 

213 

220 

194 

(4)222 


10/yr 

38 

61 

159 

198 

205 

181 

(5) 211 


12/ yr 

36 

58 

150 

187 

194 

170 

(6) 196 



Notes: 1. RUPC flight costs include refurb costs, and replacement after every 7th 
use. 

2. All launches are from ETR except T-IIG (refurb), from WTR. 

3. T-IV w/CTF if T-IV NUS + CTF. 

4. HR T-IV w/RPC column is for T-IV only; RPC not included; number In 
parentheses is number of human flights out of year's total. 

5. T-II w/RUPC column is for HR T-n only, RUPC not included. 

6. RUPC cost/flight does not include T-II; total CPF for RUPC + T-II is the 
sum of figures in both columns. 

7. Flight rate for each column is considered in isolation, except as noted 
above. 
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b. Probability of Mission Success.- The Titan reliability philosophy has been built 
upon design simplicity, robustness, extensive testing, design for enhancement of 
reliability, and the use of high-reliability components that have been thoroughly 
tested - rather than upon redundancy. This philosophy has resulted in a very 
high success rate and has been proven to be very cost effective. Engine gimbals 
are hydraulically actuated, with the engines providing the necessary 
pressurization. Titan engines are conservative in design; for example, operating 
at very modest chamber pressures (<860 psi). No igniters are needed because of 
the hypergolic nature of the propellant pair. High ullage pressures are not 
required, and autogenous pressurization systems are used in-flight to maintain 
positive expulsion flow rates (cold gas pressurization is an option for LRB's). 
There is no coast phase associated with staging, so that positive-g maintains 
propellant feed for subsequent stage ignition. The aluminum airframe is 
rugged: the vehicle can be supported either vertically or horizontally, without 
the need for propellant tank pressurization. 

For human-rated vehicles the avionics equipment, engine actuators, and 
control paths would be made redundant. Hydraulic actuators would likely be 
replaced with electromechanical devices to gimbal the engines. 

Titan reliabilities for engines and propulsion systems are at or above the average 
across many different LV systems ("generic" failure rates), as seen in the 
following table. 


TABLE 33.3.7-4.- FAILURE RATES 



HTS 

Titan 

Reliability ( per use) 

Generic 

Historical* 

Liquid Engines 

0.9977 

0.9968 

Liquid Propulsion Stages 

0.9847 

0.9929 

Monolithic solids 

0.9983 

N/A 

Segmented solids 

0.9921 

0.9866 


* Based upon launch results since the development phase completion for Titan II 
(Dec. 1964), i.e., 2 engine failures out of 630 cases (210 flights of 3 engines each); 3 
propulsion system failures out of 420 (2 propulsion stages per launch); 1 solid failure 
in 88 flights. Note: for basic LV, does not include upper stage failures (Transtage, 
Agena, Centaur). 

The next table shows the calculated PMS, using both the HTS generic values and 
those obtained using Titan-specific, historically-based reliabilities. It should be noted 
that analytical reliabilities, based upon very detailed models, predict even higher 
reliability for the Titan family. Also, the redesign of historically anomalous 
components over the life of the program improves the reliability above those 
quoted in the table. 
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TABLE 3.3.3. 7-5 - TITAN FAMILY PMS 



Reliability Basis** 



HTS 

Titan 

Titan 

Titan 


Generic 

Historical 

Program 

Demonstrated 

Vehicle 

Rates & 
Model 

Rates + 
HTS Model 

Analytic 

Reliab. 

Performance 

Cargo Only: 





Titan IIG (NUS) 

0.9626 

0.968 

N/A 

1.000 (15/15) 

Titan m/Cmrl Titan 

0.9307 

0.958 

N/A 

0.968 (150/155) 

Titan IV (NUS) 

0.9307 

0.958 

0.978 

1.000 (5/5) 

Titan IV/Centaur 

0.9100 

N/A 

0.936 

N/A 

"Titan IV (CTF/LRV) 
same, but CTF1- 

0.9242 

0.937 

0.963 

N/A 

N/A 

eng out 

0.9519 

0.973 

N/A 

N/A 

"Titan Evol (LDC) 
"Titan Evol/Centaur 

0.9185 

N/A 

N/A 

N/A 

Crew Carriers: 

0.9323 

0.938 

N/A 

N/A 

"HR Titan IIS (RUPC) 
"HR Titan IV (RPC) 

0.9189 

0.967 

N/A 

N/A 


* Postulated designs (subject to change) 

""First two columns use HTS failure model, but different failure rates (see Table 
3.3.3.T-4). Third column contains Martin Marietta internal Titan Program 
estimates. 

c. Human Safety - The Titan vehicle has high reliability and safety performance as 
demonstrated by the flight history since initial development, including the 
perfect success in launching the human Gemini spacecraft. 

Because the hydrazine-based fuels are intrinsically difficult to explode, the safety 
risk from a major breech of a propellant tank is considerably less than with 
other, more combustible fuels. When both fuel and oxidizer come into contact, 
the fire-like reaction tends to drive the two sources apart. Titan tanks are 
structurally independent, thereby minimizing this probability (except in the case 
of an induced destruct, which for untended missions purposely opens both 
tanks at their interface in order to facilitate burning and thereby reduce the 
amounts of raw propellants reaching the ground). For the same reason, fire 
propagates relatively slowly, allowing longer times for escape via a launch 
escape system (LES). 

Both HR Titans will be safer for crews than the Titan cargo launch vehicle (LV), 
because (a) the HR T-IV has no solids and (b) each solid on HR T-IIS is small 
(only 2 percent of the amount of propellant of one Space Shuttle SRB) and 
located more than 50 ft from the crew capsule. Even failures involving larger 
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solids, such as the 5.5 segment version, can allow sufficient time for escape if the 
LES is activated prior to the vehicle destruct system. In the 1988 T-34D failure, 
where the vehicle underwent on-board automatic destruct, more than 3 seconds 
were available from the time of burn-through until the fireball reached the 
payload area. Projectiles, apparently, only propagated outside a conical shadow 
zone, preventing the payload zone from suffering direct hits by debris. 

d. Architecture Cost Risk.- For the HTS, the Titan Family is defined as a 
minimum set of readily-developed vehicle derivatives from the existing family 
of operational LV's. Evolved vehicles are achieved by solid rocket additions or 
improvement programs. As an example, the Titan IIS, incorporating strap-on 
graphite-epoxy motors (GEM's) (or Castors), is already in advanced study and 
being proposed for nearer-term applications, such as MLV-3, for next-phase GPS 
deployment. The most significant new development would be LRB's for the 
HR T-IV, involving a new core diameter and a cluster of multiple engines, with 
engine-out capability. Development risk is mitigated by using existing core 
engines and the same propellants. 

Human rating of Titan is not considered a development risk because of the good 
safety features of the LV and the personnel carriers being considered; the 
Gemini-Titan system and the Space Shuttle retum-to-flight assessment 
heritages will aid the rating process. 

e. Operational Flow - At WTR, a two-pad Space Launch Complex is available for 
Titan launches. Titan IVs are launched from complex SLC-4E; Titan IIs from 
SLC-4W. A common Launch Operations Building also includes the launch 
control center, but each pad utilizes a separate mobile service tower and 
appropriate consumables facilities. Currently, the LV's are assembled on-pad, 
resulting in longer times between launches (appropriate to low launch rates), 
but future plans call for off-pad assembly concepts. 

At ETR, two Launch Complexes (LC-40 and LC-41) are now available for 
launching Titan III and IV. With minor pad modifications. Titan II could also 
be launched at these complexes, but studies underway address options for a 
dedicated Titan II complex using existing facility infrastructure. To support 
LC-40 and -41, a Vertical Integration Building has four cells. A new solid rocket 
processing facility provides stacking and checkout of the strap-ons. A planned 
Centaur processing facility will be available in 1994. Separate modular servicing 
tools (MST's) are provided for each pad. As at ETR, the required current launch 
rate for Titans is low and pad processing times are correspondingly long, but 
higher rates will be readily achievable in the future as they have been in the 
past. 

Typical current processing flows for Titan-family vehicles used in subsequent 
architectures are shown in Figures 3.3.3.7-2 through -5. For high traffic models. 
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Figure 3.3.3.7-2.- Titan IV NUS processing (ETR). 
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Figure 33.3.7-3.- Titan IV NUS processing (WTR). 
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Figure 3.33.7-4.- Titan II/RUPC processing (ETR). 
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the flow times can be reduced through the use of more integrated components, 
multiple shifts, and the addition of facilities. 


f. Environment - The only environmental impact considered significant enough 
for evaluation is the effluents from the solid rocket motors. In all cases, these 
emissions are considerably below the Space Shuttle launch emissions because of 
the small quantities of propellants, with the T-IIS solids being a factor of 20 less 
massive and the HR T-IV having no solids at all. 
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33.3.8 Cargo Transfer Vehicle (CTV) 

System Description 

a. History - The CTV is designed to deliver NLS 1 (the heavy lift launch vehicle 
(HLLV)) strongback and attached payload elements to SSF. To do this, it must be 
capable of raising the orbit perigee to a safe altitude, remaining in a phasing orbit 
until an appropriate time in order to rendezvous with the SSF, circularizing the 
orbit, conducting proximity operations, and hovering within reach of the Mobile 
Remote Manipulator System for capture and berthing to SSF. 

b. Configuration - Raising the perigee altitude and then circularizing the resulting 
orbit requires a propulsion system with sufficient thrust to accomplish these 
objectives over reasonably short bum arcs. In addition, the CTV must have 
structural and mechanical interfaces compatible with both the launch vehicle and 
payload and/or payload carrier. Maneuvering large payloads in the vicinity of the 
SSF requires six degree-of-freedom (6- degree-of-freedom (DOF) control capability 
and communication /command capability consistent with SSF requirements on free 
flyers operating in its command and control zone. Delivery of an 80 foot 
strongback and payload weights of 100 000 pounds will require a forward 
propulsion module (FPM) on the nose of the strongback which works in tandem 
with the CTV during proximity operations to assure full 6-DOF capability. Delivery 
of a single payload may be accomplished utilizing a shorter strongback (40, 50, 60 
feet) and the CTV operating alone (no FPM) if the center of gravity is located within 
an acceptable performance envelope (e.g. 50 klb payload and c.g. of 25 feet). 

Operating in the SSF vicinity will require a high degree of reliability to insure crew 
safety and protect the SSF resource. Figure 3.3.3.8-1 shows a notional version of a 
CTV, FPM, and HLLV strongback. Weight summaries are given in Tables 3.33.8-1 
and 2. 

c. Operations.- The CTV is received from the manufacturer or from the recovery 
vehicle if the CTV is reusable. The CTV is refurbished and processed for the next 
flight in the CTV Processing Facility. The CTV Processing Facility consists of a 
receiving area, two clean room processing cells (class 100K), work areas, and a local 
control area. Activities occurring in these areas include inspection, cleaning, and 
purging; vehicle system test and checkout; and hypergolic propellant deservicing. 
Automated control and checkout operations are accomplished with local Launch 
Processing System (LPS II) stand-alone test equipment. Upon satisfactory 
completion of CTV checkout the vehicle is shipped to the payload encapsulation 
facility (PEF). The CTV processing flow is shown in relationship to the NLS 
processing in Figure 333.8-2. 
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Module Module 


Notes: (1) that the ACS and feeds are common with NLSUS. SSF requirements may drive the CTV ACS 
and feed system to more redundancy that needed for NLSUS' mission. 

(2) that prox ops are conducted with mon-prop. This Is an issue to be worked with SSF. Current 
plans are to utilize biprop for prox ops, just as the Orbiter does. 

(3) that CTV will require "moderate avionics development. Avionics - Software development and 
validation in particular - are a significant part of the program. 

(4) ILS 2001 @ KSC 

* Note that the reference CTV is reusable. If trades indicate no payoff for a reusable system, the 
Shuttle-compatible fittings will not be needed. In addition, the CTV would not be driven by Orbiter 
requirements for saling of the propulsion system or by the structural design requirements for landing 
in the Orbiter. 


Figure 3.3.3.8-1 - The CTV circulation module, proximity operations module, and 
forward propulsion module. 
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TABLE 3.3.3.8-1 - CTV WEIGHT SUMMARY (POUNDS) 


AVIONICS 



Prime Power 

0 


Space Shuttle/SSF Umbilical 

80 


Cables 

50 


GN&C 

35 


Communications 

0 


Data & Instrumentation 

12 


Range Safety 

150 


FPN Umbilical 

30 


Subtotal 


357 

PROPULSION SYSTEM 



Propellant Tank 

160 


Press urant Tank 

67 


RCS Thrusters (12-25 Lbt) 

26 


Propellant Feed System 

71 


Subtotal 


324 

STRUCTURES (Includes Thermal) 



Passive Berthing Mechanism 

208 


Berthing Adaptor/Support Structure 

292 


Forward Structure and Fittings 

318 


Main Frame Structure & Keel Fittings 

152 


Avionics Support Structure 

50 


Aft Structure & Fittings 

318 


Engine Support Structure 

24 


Tanks Support Structure 

65 


Grapple Fixture 

25 


Subtotal 


1452 

CONTINGENCY (10%) 


213 

TOTAL DRY WEIGHT 


2346 

RESIDUALS &GN2 


73 

TOTAL (BURN-OUT WEIGHT) 


2419 

PROPELLANT LOADING 


1043 

TOTAL LAUNCH WEIGHT 


3462 
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TABLE 3.3.3.8-Z- CTV WITH PROXIMITY OPERATIONS MODULES 
WEIGHT SUMMARY (POUNDS) 


AVIONICS 

Prime Power 810 

Space Shuttle/SSF Umbilical 350 

Cables 900 

GN&C 478 

Communications 349 

Data & Instrumentation 536 

Range Safety 80 

FPN Umbilical 150 

Subtotal 3653 


THERMAL CONTROL 400 


PROPULSION SYSTEM 

Propellant Tank 1045 

Pressurant Tank 289 

RCS Thrusters (12-25 Lbt) 197 

Propellant Feed System 317 

Subtotal 2062 


STRUCTURES (Includes Thermal) 


Passive Berthing Mechanism 208 

Berthing Adaptor/Support Structure 292 


Forward Structure and Fittings 864 

Main Frame Structure & Keel Fittings 904 

Avionics Support Structure 500 

Aft Structure & Fittings 864 

Engine Support Structure 48 

Tanks Support Structure 130 

Grapple Fixture 25 

Subtotal 3835 


CONTINGENCY(10%) 995 


TOTAL DRY WEIGHT 10945 


RESIDUALS & GN2 | 609 


TOTAL (BURN-OUT WEIGHT) 11554 


PROPELLANT LOADING 10000 


TOTAL LAUNCH WEIGHT 21554 
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Figure 33.3.8-2 - NLS/CTV processing. 


Performance 


The performance characteristics of the CTV /NLS are given in Table 3.33.8-3. 


TABLE 333.8-3.- CTV /NLS PERFORMANCE CHARACTERISTICS 


Destination 

SSF 

Low LEO 


Orbit Alt 

220 X 220 

160 X 160 


Inc/ Element 

28.5 Deg 

28.5 Deg 


CTV/NLS 1 

101 Klbs 

105 Klbs 


CTV/NLS 2 

26 Klbs 

30 Klbs 

30X15 
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Attribute Values 


a. Funding Profile Summary.- The data shown in Table 3.3.3.8-4 was used in 
calculating the CTV's contribution to the funding profile attribute in those 
architectures utilizing the CTV. 


TABLE 33.3.8-4.- FUNDING PROFILE SUMMARY CARGO 
TRANSFER VEHICLE (MILLIONS OF $) 



Total Cost 

TFU 

LC% 

RC% 

DDT&E 

$461 




Non-Rec. Facilities 

$22 

Non-Rec. Production 

$0 

Rec. Production 





Reusable Hardware* 


$63 

90% 

100% 

Expendable Hardware* 


$16 

90% 

100% 

Overhauls 


$14 

90% 

100% 

Launch Ops. 


$25 

90% 

100% 

Cost Per Flight 

$25 Ave. For 79 Flights 


* Reusable Hardware = Kickstage + Prox Ops Module 
** Expendable Hardware = Strongback + Forward Prop Module 


b. Probability of Mission Success.- The PMS of the CTV was not separately calculated. 
The mission phases of the CTV were, however, included in the success trees of the 
NLS and used to determine the PMS of the CTV/NLS combination. 

c. Human Safety.- Not applicable, not flown with human-tended vehicle. 

d. Architecture Cost Risk.- Two of the three subattributes were based on 

system/ element values or scores. For the CTV, the NTT consensus values for those 
subattributes, are shown in Table 3.33.8-5. 

e. Launch Schedule Confidence.- Not applicable, not in critical path of NLS 
processing. 

f. Environment - Not applicable, only operates outside atmosphere. 
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TABLE 3.33.8-5.- CTV/NIO CONSENSUS VALUES 


Technical Challenge 


Non-recurring 

4 

Recurring 

3 

Operations 

3 

Program Immaturity 

6 
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33.3.9 National Launch System (NLS) 

System Description 

a. History.- The NLS is a new space launch system that is evolutionary in nature 
and is based upon the following engineering development and study activities: 
The Space Transportation Architecture Study in 1985-1986; the "clean sheet 
design approach" of the ALS studies in 1987 through 1989; the NASA Shuttle- 
derived cargo vehicle (Shuttle-C) studies conducted in 1985 through 1990; the 
Space Transportation Main Engine (STME) development starting in 1988 and 
continuing to the present; and the Advanced Launch Development Program 
system design and technology program in 1989 through to the present time. 

A DOD Milestone Defense Acquisition Board, held in September 1988, validated 
the requirements for a new, untended space launch system for cargo transport in 
the late 1990's and beyond. This new family of vehicles is proposed to share 
space launch traffic demands with the Titan, Space Shuttle, Delta, and Atlas 
systems by providing increased launch capacity and availability at reduced cost. 
The Advisory Committee on the Future of the U.S. Space Program (i.e. the 
"Augustine Committee"), December 1990, recommended the following: 

• Offload Space Shuttle in all but the initial phases of the SSF deployment, 

• Provide an evolutionary vehicle potentially capable of fulfilling the SEI, SDI 
support, lunar base and Mars trip requirements, 

• Incorporate advanced launch vehicle technologies where and when feasible, 

• Reduce operational personnel requirements, 

• Be capable of being human-rated. 

A meeting with Vice-President Quayle, DOD, NASA and Office of Management 
and Budget (OMB) representatives on January 2, 1991 recommended that this 
new launch system program would be jointly funded and managed by the Air 
Force and NASA. The new program would: 

• Provide a range of payload capabilities including heavy lift, 

• Provide a human-rateable capability for some applications, 

• Provide for an evolutionary near-term capability and a longer term 
capability that incorporates new technology. 
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• Achieve significant improvements in operations cost (particularly launch 
support manpower) and operational resilience compared to existing 
systems. 

b. Configuration(s).- The following provides summary descriptions of the NLS 
vehicle family. 

NLS 1 - HLLV 


The 100 klb class vehicle has been designated as NLS 1 (HLLV). NLS 1 is comprised 
of a propulsion module, a version of the common core (with propellant tanks), two 
advanced solid rocket motors (ASRM’s), a payload transition or adaptor section, and 
a payload carrier section consisting of a payload fairing. This fairing has a strongback 
to carry Space Shuttle payloads (in a similar manner as the Space Shuttle Orbiter). 
NLS 1 has the capability to add a CTV with an orbital propulsion and avionics 
system to deliver cargo to the SSF. All engines are pad ignited and the ASRM's 
bum to their pro-pellant depletion, at which time they are jettisoned and recovered 
from the ocean. The four STME engines burn to orbital insertion of a 30 x 200 nmi 
orbit and are shutdown by a guidance computer signal. If required to maintain a 
longitudinal acceleration limit, the STME's may be step- throttled down or two 
engines cut off prior to orbital insertion. The payload is separated from the payload 
adaptor and the remaining core is targeted for disposal with ocean impact. 

The primary mission of NLS 1 is to deliver an 80 klb (net) payload to the SSF in a 
220 nmi circular orbit. A configuration drawing is shown in Fig. 3.3.3.9-1. 

NLS 2 (Stage- and-One-Half 50 k Vehicle) 

NLS 2 has been designated as a stage-and-one-half (1.5 stage) vehicle reflecting the 
engine bum profile. Six STME's are ground-ignited and burn until correct staging 
velocity, at which time four are shut down and jettisoned. The remaining two bum 
until orbit is achieved and are shutdown by a guidance computer signal. 

NLS 2 is comprised of a propulsion module, propellant tanks ("common core"), a 
payload transition or adaptor section, and a Titan IV payload fairing. This 
configuration is to deliver a 50 klb payload to an 80 by 150 nmi orbit at an inclination 
of 28.5°. Any further orbital maneuvers will be performed by the payload, which 
may include an upper stage. A configuration drawing is shown in Fig. 3.3.3.9-2. 
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• ASRM Boosters 

• Core Propulsion Module Located Under the 
Propellant Tanks 

- STME's (4) 

-- 583Klb Vac. Thrust (650K Jan 92 
-- 430.5 s Vac. Isp 

— 45:1 Exp. Ratio 

- 6:1 MR 

— Step Throttleable (75%) Optional 

- Engine Out Capability 

- Propellant Feed System Commonality with NLS 
2 (1.5 Stage) Propulsion Module 

• ET Derived Core Tankage 

- A1 2219 Construction 

- 5 ft. Stretch in LH2 Tank 
(Wp ~ 1.69 Mlb) 

- Includes Structural Weight Penalty for 
Commonality with 1.5 Stage 

• Titan IV Derived Payload Shroud with Space 
Shuttle Compatible Attachments 

- 15' x 80' Payload Envelope 

• Kickstage / CTV for Circularization and SSF 
Rendezvous & Dock 

• 1990 Technology Avionics with Moderate 
Development 

• ILC ~ 2001 @ KSC 


Figure 3.3.3.9-1.- NLS 1 HLLV. 




• Core Propulsion Module Located Under the 
Propellant Tanks 

- STME’s (6 -- 4 Staged in Booster Module, 2 in 
Sustainer) 

— 583 Klb Vac. Thrust (650K Jan 92) 

— 430.5 s Vac. Isp 

— 45:1 Exp. Ratio 

— 6:1 MR 

-- Step Throttleable (75%) Optioned 

- Booster Module Initially Expendable 

- Engine Out To Orbit Capability 

- Propellant Feed System Common with Inline 
NLS 1 (HLLV) Propulsion Module 

• ET Derived Core Tankage 

- A1 2219 Construction 

- 5 ft. Stretch in LH2 Tank (Wp ~ 1.69 Mlb) 

- Design for Commonality with Inline NLS 1 

• Standard Titan IV Payload Shroud 

- 15’ x 61.7' Payload Envelope 

• 1990 Technology Avionics with Moderate 
Development 

• ILC ~ 2001 @ KSC and 2002 @ CCAFS 


Figure 3.3.3.9-2.-NLS 2 vehicle. 


NLS 2 with NLSUS (Two-and-One-Half Stage (2.5 Stage)) Vehicle 

The NLS 2 with NLSUS (2.5 stage) vehicle is so designated because it consists of the 
basic NLS 2 (1.5 stage), plus a new, high energy upper stage, NLSUS. The primary 
requirement for this vehicle is to deliver a 15 klb payload into geosynchronous 
orbits. Another possibility is an 80 klb (net) NASA resupply payload to SSF. A 
configuration drawing is shown in Figure 3.3.3.9-3. 
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• Core Propulsion Module Located Under the 
Propellant Tanks 

- STME's (6 -- 4 Staged in Booster Module, 2 in 
Sustainer) 

- 583 Klb Vac. Thrust (650K Jan 92) 

-- 430.5 s Vac. Isp 

-- 45:1 Exp. Ratio 

- 6:1 MR 

— Step Throttleable (75%) Optional 

- Booster Module Initially Expendable 

- Engine Out To Orbit Capability 

- Propellant Feed System Common with Inline 
NLS 1 (HLLV) Propulsion Module 

• ET Derived Core Tankage 

- A1 2219 Construction 

- 5 ft. Stretch in LH2 Tank (Wp ~ 1.69 Mlb) 

- Design for Commonality with Inline NLS 1 

• Standard Titan TV Payload Shroud 

- 15' x 61.7' Payload Envelope 

• 1990 Technology Avionics with Moderate 
Development 

• ILC ~ 2001 @ KSC and 2002 @ CCAFS 


Figure 33.3.9-3.- NLS 2 with NLSUS. 


NLS 3 (20 K Vehicle) 

NLS 3 consists of an 18 ft diameter first or booster stage with a single STME, a 
NLSUS second stage (common with the 2.5 stage vehicle), a payload adaptor, 
and an Atlas-derived payload fairing. NLSUS will be powered by a one or two 
RL-10A-4 derivative engine or equivalent. This vehicle satisfies user 
requirements for advanced MLV payloads in low-Earth orbits. Current studies 
will resolve what thrust level is needed in the booster STME (up to 640 k). A 
configuration drawing is given in Fig. 33.3.9-4. 


3.3-71 


Rev. E 




• Core Tanks are 18 feet in diameter 

- STME's (1 to 2) 

- 583 Klb Vac. Thrust (650K Jan 92) 

- 430.5 s Vac. Isp 
-- 45:1 Exp. Ratio 

- 6:1 MR 

- Step Throttleable (75%) Optional 

- Booster Expendable 

- Propellant Feed System Components Piece-part 
Commonalty with Larger Propulsion Modules 

• New Tankage Design 

- A1 2219 Construction (AL-LI is Optional) 

- (Wp ~ TBD Mlb) 

- Design for Ease of Growth. 

• Upper Stage is the NLSUS 

• Standard Atlas Payload Shroud 

- 10'x 21’ Payload Envelope 

• Advanced Technology Avionics 

• IOC ~ 2004 @ CCAFS 


Figure 3.3.3.9-4.- NLS 3 vehicle. 


NLS High Energy Upper Stage 

A high energy LOX/LH 2 powered top stage is required for the high orbits of the 
2.5-stage missions and also for the 2-stage, 20 k payload LEO mission configu- 
ration. Tentatively, the NLSUS diameter is 15 ft., and contains about 
47 000 lbs of useable propellant (exact quantity is TBD). One or two RL-10A-4 
derivative engines of ~30 k vac thrust, or equivalent single engine, may be 
required. When utilized, NLSUS will incorporate the standard avionics suite 
developed for the family of vehicles. A configuration drawing is given in 
Fig. 3.3.3.9-5. 

c. Operations.- The goal of the NLS ground operations program is to influence 
launch vehicle, facility, and equipment designs to the extent necessary to 
produce an operations flow free of complicated equipment and labor intensive 
activities, and which is characterized by rapid, dependable timelines. 
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STAGE CHARACTERISTICS 

• New Cryogenic Top Stage 

- One or Two RL-10A-4 Equivalent Engines 

- 20-40Klb Vac. Thrust (30Klb Nominal) - 450-465 
sec. Vac Isp (455 sec Nominal) 

- 100:1/300:1 Exp. Ratio (110:1 Nominal) 

- 5.5:1 /6.5:1 Mixture Ratio (6:1 Nominal) - 
Retracted Nozzle Optional 

• Advanced Structure (AL/LI) w/Mass Fr. 0.88 

• Wp~47Klb 

• Stage Weight (Wet) ~ 54Klb 

• Length ~ 30 Ft. 

• Diameter ~ 15 Ft. 

• ILC ~ 2001 @ KSC 


Figure 3.3.3.9-5.- NLS high energy, upper stage vehicle. 


Streamlined operational concepts will be designed to accomplish launch vehicle 
manufacturing, assembly, and checkout with as few facilities, tests, and labor 
intensive operations as possible. This goal will be met through proper 
application of existing and advanced technologies to satisfy the operability 
requirements set forth in the NLS Systems Requirements Documents (SRD). 

NLS ground operations are based on the Integrate-Transfer-Launch (ITL) 
processing concept. Summary ground operations flows are shown in Figures 
3.3.3.9-6 through 3.3.3.9-8. This process features the integration of the flight 
vehicles off-pad with subsequent transfer to the launch pad on a mobile 
platform. The process begins with the final assembly and/or checkout of large 
vehicle elements adjacent to the launch site. After each vehicle element is 
assembled and checked out, it is transferred to the Vehicle Integration Facility 
(or Vertical Assembly Building) where all elements are integrated into a single 
launch vehicle stack on a Mobile Launch Platform (MLP). The locations and 
inter-relationships of the NLS operations facilities are shown in Figure 3.3.3.9-9. 
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Figure 3.33.9-6- NLS 1 processing (NLS HL). 



Figure 33.3.9-7.- NLS 2 processing (NLS 50). 
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Figure 3.3.3.9-8 NLS 3 processing (NLS 20). 



Figure 3.3.3.9-9- NLS operations facilities. 
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Individual spacecraft and upper stages are processed in dedicated (non-NLS) 
facilities. When ready for integration, they are transported to the NLS Cargo 
Integration Facility (CIF) where upper stages are mounted to the NLS standard 
cargo adapter, and spacecraft are mounted either to the upper stages or to the 
cargo adapter as required. After cargo interfaces are validated, till cargo elements 
are serviced and NLS personnel assemble the fairing to encapsulate the cargo. 
The integrated cargo, encapsulated in the fairing, is brought to the Vehicle 
Integration Facility (VIF) and mounted on top of the stack. The cargo-to-vehicle 
interfaces are then validated and the MLP moves to the launch stand. The 
simplified interfaces between the MLP and the launch stand are mated and 
validated with a final systems test. After the systems test, cryogenic propellants 
are loaded and the vehicle is launched. Although there are no fixed towers or 
mobile gantries at the launch stand, the MLP does incorporate an umbilical mast 
to provide standard payload services. 

The LCC supports prelaunch preparation and tests, launch and mission 
operations, and performs facility monitoring. This operations approach 
provides efficient planning and use of the launch stand(s), allows parallel 
processing, isolates the launch stand from the build-up area, and facilitates 
launch vehicle and payload changeout. 

Recoverable vehicle elements (booster engines and possibly core propulsion and 
avionics) are recovered and processed through refurbishment facilities to ready 
them for their next flight. 

Current siting concepts call for the eventual construction of launch operations 
facUities at KSC, CCAFS, and VAFB. 

Performance Characteristics 


The performance of the NLS family of launch vehicles, including performance with 

CTV, CTF, RPC, and CRV, is contained in Table 3.3.3.9-1. 

Attribute Values 

a. Funding Profile Summary.- The data in Tables 3.3.3.9.2 through 3.3.3.9-4 was 
used as input for the calculation of the funding profile attribute. 

b. Probability of Mission Success.- The flight phases used for calculating PMS are 
based on the event trees for the NLS. These are described in the section 
describing the PMS attribute. Vehicle characteristics, which effect the calculation 
of PMS, follow. 
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TABLE 3.3.3.9-1.- NLS VEHICLE FAMILY PERFORMANCE 
VEHICLES/PERFORMANCE (1,000 LB) 


Orbit* 

NLS 

NLS 100 

NLS 100 

NLS 

NLS 50 

NLS 50 

NLS 20 


100 

W/CTV 

W/AUS 

50 

W/CTV 

W/AUS 

W/AUS 

SSF 220X220 28.5° 


101.0 



26.0 



LEO 160X160 28.5° 


105.0 


49.7 

30.0 



150X150 90° 




31.0 



4.0 

445X445 98.7° 




13.6 




SSF xfer 30x220 
28.5° 

45.0 







NLS xfer 80x150 
28.5° 

142.0 



51.0 



19.3 

GTO 



39.0 



8.3 


GEO 



19.5 



4.2 


Usable Payload 
Vol (L x D in Ft) 

90x30 

60x30 

30x15 

60 x 15 

30x15 

H 30x15 

30x15 


*Only orbits used in manifesting are shown 


TABLE 3.3.3.9-Z- FUNDING PROFILE SUMMARY NLS 20 VEHICLE 

(MILLIONS OF $) 



Total Cost 

TFU 

LC% 

RC% 

DDT&E 

$218 




Non-Rec. Facilities 





Vert Proc Fac 

$139 




Horiz Prod Fac 

$154 




MLP 

$62 




Non-Rec. Production 

$0 




Rec. Production 





Core 


$17 

90% 

87% 

STME 


$14 

94% 

94% 

Shroud 


$1 

90% 

100% 

AUS j 


$22 

90% 

90% 

Cost Per Flight 

$64 Ave. For 64 Flights 
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TABLE 33.3.9-3.- FUNDING PROFILE SUMMARY NLS 50 VEHICLE 

(MILUONS OF $) 



Total Cost 

TFU 

LC% 

RC% 

DDT&E 

$4,991 




Non-Rec. Facilities 





Pad 

$278 




Vert Proc Fac 

$248 




Horiz Prod Fac 

$57 




MLP 

$144 




Other 

$789 




Non-Rec. Production 

$83 




Rec. Production 





Core 


$99 

90% 

87% 

6 STME @ 


$14 

94% 

94% 

Shroud 


$8 

100% 

100% 

AUS 


$22 

90% 

90% 

Cost Per Flight 

$87 Ave. For 310 Rights | 


TABLE 33.3.9-4.- FUNDING PROFILE SUMMARY NLS 100 VEHICLE 

(MILUONS OF $) 



Total Cost 

TFU 

LC% 

RC% 

DDT&E 

$120 




Non-Rec. Facilities 





Pad-Mods 

$70 




Vert Proc Fac Mods 

$4 




Cargo Prod Fac 

$117 




MLP-Mods 

$82 




Other 

$104 




Non-Rec. Production 

$0 




Rec. Production 





Core 


$99 

90% 

87% 

4 STME @ 


$14 

94% 

94% 

Shroud 


$18 

100% 

100% 

AUS 1 


$22 

90% 

90% 

ASRM 

$31 Rec Per Flight (2 Motors) 

Cost Per Flight 

$127 Ave. For 146 Flights 
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• All vehides have hold-down capability. 

• The NLS 50 and NLS HL have engine-out capability. 

• The number and type of engines and stages are given in Figures 3.3.3.9-1 
through 3.3.3.9-5 for each of the vehicles and/ or elements. 

The calculated values for PMS for each of the vehicles are as follows: 


NLS 20 

0.9435 

NLS 50 

0.9842 

NLS 50/AUS 

0.9455 

NLS HL 

0.9308 


c. Human Safety.- The MLS safety is discussed as an integral element of safety for 
the RPC and CLV systems. 

d. Architecture Cost Risk.- Two of the three subattributes were based on system 
values, or scores. For the NLS vehicles, the NIT consensus scores for the 
subattributes, technical confidence and program immaturity, for each of the 
vehides are given below. 


Vehicle 

Technical Confidence 

Program Immaturity 

NLS 20 

35.6 

12.9 

NLS 50 

247.9 

12.9 

NLS HL 

142.3 

12.9 


e. Launch Schedule Confidence - As with ACR, two of the three subattributes 
were based on system values, or scores. One of these, schedule compression, 
was calculated to be zero for all NLS vehicles because the nominal flows for the 
NLS, shown previously in this section, are based on three shift, 7-day per week 
operations. The other, percent of flights with delays, was calculated to be 3.22 
percent for all NLS vehicles. Both of these calculated values, along with the 
schedule margin subattribute, were subsequently used with architecture- 
particular flight rate data to roll-up the architecture LSC and value. 

f. Environment - The NLS 20 and 50 vehicles use all-LOX hydrogen propellants. 
The NLS HL uses solid boosters in addition to LOX hydrogen propellants. 

Using the appropriate propellant weights for each NLS configuration, the major 
effluent constituents (in klbs) are shown in Table 3.3.3.9-5. These values are based 
on equilibrium, non-afterburning calculations. 
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TABLE 3.33.9-5.- EFFLUENT DATA FOR NLS 


Exhaust Product 

NLS-20 


NLS-HL 

CO 

0.0 

0.0 

542.6 

CO 2 

0.0 

0.0 

48.2 

H 2 

11.8 

58.2 

108.8 

h 2 o 

331.2 

1628.2 

1813.9 

HCI 

0.0 

0.0 

479.9 

n 2 

0.0 

0.0 

197.8 

OH 


0.0 

4.8 

H 

0.0 

0.0 

2.4 

Al 2 03 


0.0 

851.3 

Total Mass 
per Flight 
(klbs) 

343 

1686.4 

4049.7 

Score 

34 

169 

6203 
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3.3.3.10 Manned Launch System (MLS) 
System Description 


a. History.- One of the perceived objectives of any new human space 
transportation system will be to maximize crew safety. For architectures that 
include human elements boosted on an expendable (or partially reusable) 
launch vehicle, the safety of the entire system is limited by the characteristics of 
the booster. For the purposes of this study, we conceptualized a hypothetical 
launch vehicle with features that could significantly enhance crew safety (as 
opposed to a performance or cost-optimized design). This vehicle was dubbed 
the MLS. 

b. Configuration.- To enhance the credibility of comparisons between similar 
architectures, it was decided to start with a booster design that was already 
included in this study and make minor changes to that design to arrive at an 
MLS. The NLS 50 k payload lift-capacity vehicle concept (or NLS-50, see section 
3.3.3.9) is very close in performance to the requirement for a MLS. The NLS-50 
also includes many of the features one would expect in a safety-driven booster 
design. Although the specifics of what human-rating implies are still subject to 
debate, certain booster attributes are desirable: 

• Robust design - high factors of safety, weight margins. 

• Integral Vehicle Health Monitoring (VHM) - sufficient sensors and 
processors to continuously evaluate system's health and to notify crew 
and/or abort system(s) in timely fashion. 

• Engine-out capability - precludes the need to initiate abort procedures (which 
are risky) in a large percentage of failure modes (many failures have included 
propulsion hardware). 

• Minimal correlated failure modes - maximize containment/isolation of 
critical subsystems. 

• Eliminate rapid failure modes - abort systems and VHM are useless if there 
is insufficient reaction time (for example, some solid propellant boosters 
failures can be detected only milliseconds before a catastrophic detonation). 

To encompass the range of missions for architectures using the MLS, a "family" 
of vehicles is required. The core stage MLS, known as the MLS-X, is sized to 
carry the RPC (see Section 3.3.3.11) with a small crew and no additional cargo to 
the SSF orbit. The MLS-X is a stage-and-one-half design featuring six STME's 
(four in expendable booster pods, and two sustainer engines) and a Shuttle 
External Tank-derived LOX/LH 2 fuel tank set. To carry larger cargo, or the 
human-tended CLV (see Section 3.3.3.12), a larger version of the MLS-X called 
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the MLS Heavy Lift (MLS-HL) was conceived. The MLS-HL features a LOX/LH 2 
upper stage in addition to the MLS-X core first stage. Figure 3.3.3.10-1 depicts the 
two MLS configurations with untended cargo fairings. Figure 3.3.3.10-2 shows 
the design of the upper stage. 


MI.S-X 

(CARGO! 


• MLS-X same as MLS-HL except has new high energy 
upper stage 


MLS-HL 

(CARGQ1 



• Standard Titan IV payload shroud for cargo versions 

- 15 ft x 61.7 ft nominal payload envelope 

• Core propulsion located under the propellant tanks 

- STMEs: 6 (4 staged in booster module, 2 in sustainer) 

- 583 Klb vacuum thrust (650 KJb in January 92) 

- 430.5 seconds vacuum Isp 

- 45:1 Expansion Ratio 

- 6:1 Mixture Ratio 

- Step throolability (75%) optional 

- Booster module initially expendable 

- Engine out to orbit capability 

• ET derived core tankage 

- AL 2219 construction 

- 5 ft stretch in LH2 tank (Wp - 1.69 Mlb) 

*1990 technology human rated avionics with moderate 



303.03 ft 


development 


Weights for 80 X 220 ran 

Orbital Insertion Performance: 



MLS-X 

MI^-HL 


RPC 

Cargo 

Cargo 

Payload: 

26,343 

43,768 

87,498 

Margin: 

13,615 

- 0 - 

-0- 

Shroud: 

2700 

13,569 

13,569 

Launch Veh. (dry): 

166,311 

199,311 

207,664 

PropellanL* 

1.704.222 

1 704.222 

1.750.3& 

GLOW: 

1.953.968 

1 960 870 

2.059.095 



Figure 3.3.3.10-1- MLS configurations. 


Physically, the MLS differs little from the NLS configurations. There are 
additional sensors and a communications bus running forward to supply VHM 
data to the crew of a personnel capsule on top of the MLS. In both versions, the 
cross beam provisions found on the NLS-50 core stage for using strap-on boosters 
are absent. 

c. Abort Modes - In the event of an engine failure, the MLS can operate engine-out 
and complete the nominal ascent profile. In the event of any other major 
failure, the on board sensing system would warn the crew to initiate abort 
procedures. The LES motor would be ignited, the MLS main engines would be 
commanded to shut down, and the attachment fittings between the crew 
element and the MLS would be severed. 
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d. Facilities.- The ground-processing facilities for the MLS are nearly identical to 
those described for NLS (section 3.3.3.9). There is no requirement for solid 
booster stacking or handling facilities, however. The launch pad will need to 
accommodate human access and safety provisions for both the MLS-X/RPC 
combination and the MLS-HL/CLV combination. The MLS launch pad 
definition includes the additional access tower and personnel preparation areas. 

e. Operational Flow.- As is the case for facilities, the operational flow is basically 
the same as for the NLS (see Figure 3.3.3.9-9), with die exception that there are no 
solid boosters to assemble or integrate. The MLS upper stage will follow a 
launch operations processing flow similar to the NLS Advanced Upper Stage and 
CTV flows (also described in the NLS section). 

Performance Characteristics 


The baseline MLS performance is based on the system’s ability to place a reference 
RPC into a SSF orbit. Accounting for the RPC’s orbital maneuvering system 
capability, this translates to the needed MLS-X capability of 43 768 lbm to an 80x220 
nmi (28.5°) orbit. Similarly, the MLS-HL performance is sized to put a CLV (87 498 
lbm) into the same orbit. 

Attribute Values 


a. Funding Profile Summary.- The MLS-X and MLS-HL launch vehicles' family 
cost estimates developed for this study are summarized in Table 3.3.3.10-1. All 
estimates shown in the table are in constant-year 1992 dollars, at contractor cost 
(the estimates exclude contractor fees, management reserves, and government 
program support costs). 


TABLE 3.3.3.10-1.- MLS FUNDING PROFILE SUMMARY 



(1992 Dollars in 
Millions) 



MLS-X 
Core Stft. 

MLS-HL 
Upper Ste. 

Development: 

$5,309 

$631 

C/D Phase 

L562 

37 (mod.'s) 

Facilities 
Total - 

6,871 

668 

Production: 

244 

47 

Theo. 1st Unit 
Supt. Equip. Set 

15 


Oper. & Support: 

34 

6 

Variable Cost 
Fixed Annual 

92 

9 
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• Acquisition Phase Estimates - New development and production estimates 
were developed by Boeing for MLS-X hardware using the Boeing-proprietary 
Parametric Cost Model. New estimates for the MLS-HL Upper Stage 
(MLSUS) were developed by McDonnell Douglas Space Systems Company 
using their proprietary parametric cost model. The two MLS estimates were 
fully coordinated with the RPC and CLV program planning schedules for the 
architecture cost estimate inputs. The MLS-X estimate was also coordinated 
with the MSFC NLS estimate sources to ensure that the STME propulsion 
subsystem estimates and schedule matched the MLS master schedule used 
for the MLS development estimate definition. 

• Operation and Support Estimates - The operations’ cost estimates data is 
shown for MLS elements only. 

• Funding Profile Attribute Cost Inputs - The data shown in Table 3.3.3.10-2 
was estimated and evaluated for annual cost estimate spread factors using 
the Figure 3.3.3.10-3 MLS program master schedule. The summary included: 
percentage factors for cost spreads, cost improvement and realization curve 
factors for theoretical first unit, cost estimate extensions to develop total 
production fleet costs, and facility usage estimates. The MLS family cost 
estimate input forms are provided in Appendix B. 

b. Probability of Mission Success.- The flight phases used for calculating PMS are 
the same as those for NLS (refer to the reliability tree of section 3.3.3.9). While 
some definitions of human-rating stress maximize reliability, it was felt that it 
would be unrealistic to claim any significant difference in component or system 
reliability from those used for NLS. The MLS-X PMS is thus equal to 0.9842 and 
the value for MLS-HL PMS is 0.9691, 

c. Human Safety.- The MLS safety is discussed as an integral element of safety for 
the RPC and CLV systems. 

d. Architecture Cost Risk.- The risk assessment of the MLS flight elements is based 
on preliminary program and design descriptions developed during the HTS 
study. The NIT average of the non-recurring portion of the Technical Challenge 
subattribute was a score of 4, reflecting the opinion that the MLS design is largely 
state-of-the-art technology. The production Technical Challenge subattribute 
score was also a 4 using similar reasoning. In the operations Technical 
Challenge subattribute, a score of 3 indicated that, since the MLS uses many 
existing facilities and procedures at KSC/ETR, there is a lower risk involved 
with operations cost estimation. The Program Imaturity score was a 6, which 
reflects the perceived level of design detail that exists at the time of this writing. 
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MLS Master Summary Schedule ^ 

Fiscal Year I FY93 | FY94 | FY95 1 FY96 I FY97 | FY98 | FY99 | FYOO~ 
Calendar Year 1993 1 1994 1995 1 1996 1997 I 1998 I 1999 I 2000 



Figure 3.3.3.10-3 - Preliminary master schedule for LCC analysis. 
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e. Launch Schedule Confidence.- As with ACR, two of the three subattributes 
were based on system values, or scores. One of these, schedule compression, 
was calculated based on the MLS operations data; since compression is based on 
additional shift utilization and MLS processing around three shifts, 7 day-a- 
week operations, the compression is zero. The other, percent of flights with 
delays, was calculated to be 3.22 percent. Both of these calculated values were 
subsequently used with architecture-particular flight rate data to roll up the 
architecture subattribute value. 

f. Environment.— The MLS booster uses liquid hydrogen and liquid oxygen as 
propellants. The MLS-X has a propellant load of 1,704,222 lbm which is identical 
to the first stage of the MLS-HL. Although the MLS-HL features an upper stage, 
this stages operates outside the sensible atmosphere and does not contribute to 
the environment score as defined in this study. 

Using the given propellant weights, the major effluent constituents (in klbs) are 
shown in Table 3.3.3.10-2. These values are based on equilibrium, non- 
afterburning calculations. 


TABLE 3.3.3.10-2.- EFFLUENT DATA FOR MLS 


Exhaust 

Product 

MLS-X 

MLS-HL 

CO 

0.0 

0.0 

CO 2 

0.0 

0.0 

h 2 

58.2 

58.2 

h 2 o 

1628.2 

1628.2 

HC1 

0.0 

0.0 

n 2 

0.0 

0.0 

OH 

0.0 

0.0 

H 

0.0 

0.0 

ai 2 o 3 

0.0 

0.0 
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3.3.3.11 Reusable Personnel Carrier (RPC) 


System Description 

a. History.- Previous space transportation architecture studies have shown that a 
promising concept for human transportation involves a compact, reusable 
personnel carrier launched on an expendable launch vehicle that would carry no 
significant integral cargo. In recent years, several types of vehicles in this class 
have been studied, most notably the JSC /Boeing Biconic PLS and the 

LaRC/ Rockwell HL-20 Lifting Body PLS. While the designs are different, their 
basic mission, size, and costs are very similar, and any one concept should serve 
as representative of the RPC and the architectures that feature it. 

b. Configuration.- The design of the RPC is based on a moderate L/D capsule 
configuration that was explored in a JSC /Boeing PLS concept definition study. 8 
The biconic capsule is launched atop an expendable launch vehicle; in the HTS 
study, launcher options include HR Titan IV, NLS-50, and the MLS-HL 
(discussed individually in subsequent paragraphs). Figure 3.3.3.11-1 depicts the 
fundamental vehicle features. 



Figure 3.3.3.11-1.- RPC general arrangement. 


The Boeing RPC biconic vehicle design includes both expendable and reusable 
hardware subsystems. The vehicle has sufficient room for personal provisions 
and perishable payloads on crew rotation missions to the SSF. In this design, the 
orbital maneuvering system and radiators are discarded during the time the 
reusable crew module section reenters the Earth's atmosphere. Other expendable 
RPC items are the LES and forward aerodynamic fairing (expended after initial 
ascent is accomplished) and most of the deployment landing parachutes 
(removed after landing.) 
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Kits for satellite servicing missions (not shown in the illustration) include a 
small manipulator arm (attached to the flat bulkhead); an additional EVA tunnel 
adapter for mission specialists’ ingress and egress in space suits is also an option. 

c. Abort Modes.- The LES for the RPC provides for a rapid removal of the crew 
module from the booster in the event of an emergency. This capability can be 
initiated anytime from prelaunch through orbital insertion. The RPC landing 
system includes redundant parafoils, which can be used just as effectively in the 
event of a water abort landing. 

d. Facilities - The RPC is treated as a special payload for the launch vehicle options. 
A separate processing facility (essentially a scaled-down version of the Space 
Shuttle Orbiter Processing Facility) is used to maintain and refurbish the RPC. 
Additional facilities include a mission and training facilities complex, 
administration facilities, and refurbishment support facilities. 

e. Operational Flow - The operations flow for the RPC is shown as 

Figure 3.3.3.11-2. The RPC design is considered sufficiently independent of the 
booster design such that the integration of the flow with the launch vehicle is a 
secondary effect. 

Performance Characteristics 

The RPC is a personnel vehicle and therefore has no payload capability to contribute 
to completing the cargo missions of the manifest. The vehicle is designed to carry 
up to six astronauts with sufficient on-orbit functionality to perform SSF crew 
rotation missions, orbital sortie missions and satellite servicing missions. 

Attribute Values 


a. Funding Profile Summary.- The cost estimates for the RPC program were 
developed on a JSC study contract in 1991 (NAS9-18255). The estimates were 
escalated from 1991 to 1992 dollars using a NASA inflation index. 

• Acquisition Phase Estimates. The Boeing PLS estimates used for the RPC 
inputs to the HTS architecture evaluation tool were developed with the 
Boeing-proprietary Parametric Cost Model, GE Price-S software cost model, 
and NASA Space Shuttle historical databases at KSC (facilities and 
equipment) and JSC (software, mission control, and training definition data). 
In addition, planning estimates for the OMS engines, LES engine (RS-27), and 
parafoil landing equipment was received from the source manufacturers of 
current equipments. The development schedule is shown as Figure 3.3.3.11-3. 
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Figure 3.3.3.11-2 - Operational flow for the RPC. 
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RPC times indicated in "calendar hours". 

Equivalent STS 51 -L function with actual "clock hours" 
converted to "calendar hours" is indicated in parentheses. 




Figure 3.3.3.11-3 - RPC development schedule. 
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• Operation and Support Estimates. Operation and support functions were 
direct task human-load estimates and factor estimates. 

• Funding Profile Attribute Cost Inputs. Table 3.3.3.11-1 contains the cost 
estimates summary for the RPC element. 

TABLE 3.3.3.11-1.- RPC COST ESTIMATES SUMMARY 



(1992 Dollars in Millions) 
Reusable 
Personnel Carrier 

Development: 
C/D Phase 

$3,693 

Facilities 

434 

Total: 

$4,127 

Production: 
Reusable TFU 

257 

Expendable TFU 

65 

Supt. Equip. Set 

13 

Oper. & Support: 
Variable Cost 

28 

Fixed Annual 

125 


b. Probability of Mission Success - The contribution of the RPC to mission success 
is limited to its post-booster separation OMS bums and coast periods before its 
destination orbit is achieved (on-orbit operations, such as docking and descent 
phases are excluded from the current definition of mission success). Since these 
represent additional branches in the ascent reliability trees, as compared to 
untended launches using similar boosters, the PMS decreases slightly, as shown 
in Table 3.3.3.11-2. Note that in two cases, the booster option is never flown 
without the RPC. 


TABLE 3.3.3.11-2.- RPC PMS 


Booster 

PMS w/o RPC 

PMS w/ RPC 

NLS-2 

0.9842 

0.9544 

MLS-X 

0.9842 

0.9544 

HR Titan IV 

n/a 

0.9188 

MLS-HL w/LRV 

n/a 

0.9543 
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c. Human Safety - The RPC design includes several features to enhance safety in 
the event of a launch vehicle failure. A launch escape system is carried 
throughout the entire thrusting ascent phase which would allow the crew to be 
pushed away from the launch vehicle. The parachute landing system can also be 
employed in the event of an unplanned water landing. Physical separation of 
the crew element and the launch vehicle is maximized by locating the RPC on 
top of the launch vehicle. The probability of loss, in the event of launch vehicle 
failure with the RPC design, is shown in Table 3.3.3.11-3. 


TABLE 3.3.3.11-3.- RPC SAFETY (PROBABILITY OF LOSS) 


Booster 

Plw/RPC 

NLS-2 

0.00542 

MLS-X 

0.00543 

HR Titan IV 

0.01237 

MLS-HL w/LRV 

0.00641 


d. Architecture Cost Risk - The development of an RPC, reflected in the non- 
recurring portion of the Technical Challenge subattribute score, was set at a value 
of 5 by the NIT, indicating the design is largely existing technology with a few 
areas that may be outside the technical state-of-the-art. The production and 
operations technical challenge scores were both a 3, reflecting the relative 
simplicity of the design and its operational scenario. Based on the status of the 
design today, considered preliminary, a score of 6 was assigned for Program 
Immaturity. 

e. Launch Schedule Confidence.- The schedule compression subattribute is highly 
dependent on which combination of booster and RPC is considered. Refer to 
section 3.2.6.3 for the values related to RPC combinations. The other, percent of 
flights with delays, was calculated to be 5.88 percent. Both of these calculated 
values were subsequently used with architecture-particular, flight-rate data to 
roll up the architecture subattribute value. 

f. Environment - The RPC contributes nothing to the score of environment as it 
operates exoatmospherically, outside the range of interest for this study's 
definition of the environment attribute. 
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3.3.3.12 Crew and Logistics Vehicle (CLV) 

System Description 

a. Requirements and Concept Selection.- To evaluate the impact of separating 
people from cargo, it is necessary to compare the Space Shuttle not only with a 
new people-only transportation system, but also with a new system which 
carries cargo as well. The people-with-cargo system is required to carry enough 
cargo to enable these additional missions: 

(1) Pressurized logistics to and from SSF 

(2) Sortie Science missions (e.g., Spacelab-type missions) 

(3) Satellite servicing. 

The cargo capacity requirement for these jobs is a tradeable variable against the 
number of missions flown. But for this study, a weight requirement of 15 000 lbs 
was levied to enable all the jobs with a minimum of remanifesting. 

One additional requirement was levied. To enable this system to replace the ACRV, 
it must be capable of up to 180 days' quiescent stay at SSF. 

All currently studied personnel carriers for early availability were reviewed: 
upgraded ACRV, upsized Boeing PLS, upsized Rockwell PLS, HL-20, and CLV. The 
CLV, which is adapted from a study led by the Systems Definition Branch of the 
Systems Engineering Division at JSC, was selected because its proposed missions 
include logistics, sortie science, and servicing. The study does not recommend a 
configuration; several of the above candidates could be modified to carry out these 
missions. The configuration for CLV (shown in comparison) is provided in 
Figure 3.3.3.12-1. 

b. Configuration.- The starting point for CLV was a scaled-down Orbiter. Linear 
dimensions are about 50 percent of Orbiter. The aft fuselage was tapered and the 
OMS pods removed to reduce drag; wing modifications were adopted to move 
the aerodynamic center forward. The following subsystem changes from Orbiter 
were made: 

• Thermal Protection - tile plus active cooling (water evaporation) 

• Propulsion - bipropellent plus cold gas nitrogen system for use in proximity 
to SSF 

• Power - long-life restartable fuel cells (hydrogen-oxygen) 

• Actuators - electromechanical 
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Bfconfc PLS 

2 crew/ 

8 passengers 


HL-20 PLS 

2 crew/ 

8 passengers 


Crew Logistics Vehicle 

2 crew/8 passengers 
15,000 lb. payload 


Space Shuttle Orbfter 

2 crew/5-8 passengers 
43,000 lb. payload 


Figure 3.3.3.12-1- Representative PC concepts. 


The CLV contains no main engines. It is designed to be launched on a human-rated 
ELV. The NLS-1 heavy-lift vehicle could have been used, but has much more 
capability than is needed. It was decided to adopt a series of human-rated boosters 
from the NLS family which are optimized for human missions - the MLS family. 
CLV is launched on the MLS-HL, whose GLOW is optimized for this purpose. See 
section 3.3.3.10 for a more detailed description of the MLS-HL. 

c. Abort Modes - Abort coverage is provided during all launch phases as follows: 

(1) First stage: abort motors provide contingency abort from liftoff; ejection 
seats provided for crew escape to 90 000 ft. Above 90 000 feet, the CLV 
would glide to a lower altitude for crew ejection. 

(2) Second stage: abort motors provide press-to-main-engine-cutoff capability 
from second stage ignition with one engine out for benign failures, or 
intact abort (transatlantic or once-around) for catastrophic failures. 
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d. Facilities and Operational Flow - The CLV takes over Space Shuttle facilities at 
KSC as the Space Shuttle is phased out. The following figure shows the ground 
processing flow for CLV. 



5 day 1 shift 


Figure 3.3.3.12-2 - CLV operational flow. 


Notes: 

(1) Postflight refurbishment time is longer for sortie and satellite servicing 
missions because mission kit installation is required for these missions. 

(2) Major overhaul is required every 30 flights or 4 years and takes 6 months. 
Six-day time shown is prorated average per processing flow. 

Ground processing time (neglecting flight time) varies from 60 to 80 days 
depending on the mission (see Figure 3.3.1.12-2 above). The number of 
flights per year, per CLV is most strongly dependent on flight duration, and 
varies from four per year for sortie mission to three every 2 years for SSF 
missions of 180 days' duration. If the CLV is not required to perform the 
ACRV function, all vehicles can be utilized at four flights per year. 

Initial Operational Capability is in June of 2000. Figure 3.3.3.12-3 shows the 
DDT&E Schedule. 

The CLV remains in use throughout the study period (to 2020). 
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Performance Characteristics 

The following table shows the key performance characteristics of CLV. 


TABLE 3.3.3.12-1.- CLV PERFORMANCE CHARACTERISTICS 


Launch Vehicle 

MLS-HL 

GLOW (lbs.) 

86,700 

Length (ft.) 

54 

Height (ft.) 

28 

Wingspan (ft.) 

47 

Pressurized Volume (ft3) 

1,650 

Cargo envelope 

7.5 ft. diam x 36.5 ft. length 

Cargo capacity (220 NM circ, 28.5°) 

15,000 lbs. (up & down) 

Human Vehide Crew capability 

Six (four plus vehicle crew ) 

Mission duration 

5 + 2 d. active, 180 d. quiescent 

Max Q 

1000 psf 

Max G 

4.5 

Delta V capability 

1000 fps. 

Landing speed 

185 knots 

Launch site limitations 

Same as Space Shuttle 


Attribute Values 


a. Funding profile.- The following table shows the CLV/MLS-HL system costs. 


TABLE 3.3.3.12-2.- CLV/MLS-HL SYSTEM COSTS, $M FY92 



CLV 

MLS-HL 

DDT&E 

7,050 

4,091 

p3i 

7,410 

385 

Non-Recurring Prod. 

Included in DDT&E 

380 

Facilities 

Included in DDT&E 

4,130 

Recurring Prod. 

737 per vehide 

113 per vehide 

Cost per Flight at 
10 Flights/year 

267* 



* Includes MLS-HL and wraps. 
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b. Probability of Mission Success - Reliability estimates based on the CLV/MLS-HL 
vehicle configuration (six engines in first stage, three in second stage, engine-out 
capability in both), reliability tree, and historical data for characterized 
subsystems results in a combination score of .9543. 

c. Human Safety.- The PMS data given above predicts a launch failure rate of 45.7 
per thousand flights. The loss rate per thousand flights for CLV is estimated as 
6.41. The CLV's high score relative to other systems studied is attributable to its 
full abort coverage and separation of people from the main engines. 

d. Architecture Cost Risk.- The CLV received a Technical Challenge rating of 
approximately 240 for "If" C (the range for all systems was 0 to 3000), and a 
Program Immaturity rating of 21.5 (the range was 1 to 100). The CLV is judged 
to require no new technology; only a few existing drawings can be used, but they 
are based on a familiar product line. 

e. Launch Schedule Confidence - The ground processing flow is shown in Figure 
3.3.3.12-2. The ability of CLV/MLS-HL to achieve schedule compression 
depends on the mission, since, as shown in the figure, ground processing time 
varies. An average compression is 20 days out of a processing flow of 72 days. It 
was estimated that 14.58 percent of CLV/MLS-HL flights would experience 
delays due to unscheduled maintenance. 

f. Environment - The CLV contributes nothing to the score of environment as it 
operates exoatmospherically, outside the range of interest for this study's 
definition of the environment attribute. 
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3.3.3.13 Reusable Ultralight Personnel Carrier (RUPC) 

System Description 

The primary mission of this vehicle is to transport crew to and from Earth orbit, 
with an emphasis on supporting crew rotation for SSF. The primary design 
reference mission is for accommodating six persons for 5 days, although rendezvous 
with SSF is nominally accomplished in four revolutions or less. Up to six SSF crew 
persons may be returned because the RUPC entry-landing sequence is fully 
automated and does not require a high level of piloting proficiency. 

To provide a system which has the lowest feasible cost using an existing ELV, the 
RUPC has been designed under the constraint that it can be lofted by a Titan-HS, 
which therefore requires a lower mass than comparable PLS designs. The penalty 
for such a requirement includes higher development costs, using advanced 
materials and advanced equipment, and designing for advanced manufacturing 
techniques. These higher DDT&E costs are assumed to be compensated over the 
long term by significantly lowered costs for launch, refurbishment, and other 
recurring expenses. In many cases, the RUPC design capitalizes on previous 
programs (e.g., Gemini aerodynamics, Apollo recovery system. Space Shuttle 
thermal protection system (TPS), planetary mission and DOD-sponsored avionics 
developments) and space infrastructure that did not exist when previous human 
systems were developed (e.g., TDRSS, GPS, SARSAT). 

The system includes three units: a capsule, an adapter, and an escape tower, as 
shown in Figure 3.3.3.13-1. The pressurized capsule is reusable for seven flights (on 
the average), but the other two units are expended on each flight. Within the 
capsule is a fully pressurized crew cabin, made from lightweight composite 
materials, sufficient to house crew and small amounts of cargo for SSF, satellite 
servicing, or modest sortie science. Configuration of the capsule accommodates the 
following requirements: (1) aeroshield shape to satisfy reentry control and heating 
requirements, (2) inclusion of a SSF passive Common Berthing Mechanism (CBM) 
at the narrow end of the cone, and (3) aerodynamically compatible shape to 
minimize afterbody heating (18° cone half-angle). Avionics, recovery systems, 
forward RCS, and entry power systems are also located in the capsule. Thermal 
protection is provided by advanced reusable insulation, derived from Space Shuttle 
TPS materials. 

The adapter configuration is determined by the necessity to provide the mechanical 
support to transition from the larger-diameter RUPC to the 10-ft diameter Titan-II 
second stage. Within the adapter are the main power system and the OMS and aft 
RCS propulsion systems. The same system is also used for rendezvous 
maneuvering and deorbit. Engine-out maneuvering capability is provided, as well 
as redundancy in valving and valve drivers, and cross-strapped propellant feeds. 
Storable hypergolic bipropellants (MMH and NTO) are utilized for all RUPC 
propulsion. 
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Figure 3.3.3.13-1- The RUPC /Titan IIS system. 

An LES is provided to enable the capsule to be rapidly ejected from the launch stack 
in the event of a major launch malfunction. This LES, containing a single solid 
with multiple canted nozzles and a smaller jettison solid rocket, is modeled after, 
but downsized from the Apollo LES (see discussion below under Safety attribute). It 
allows both the rapid escape from a malfunctioning vehicle and also sufficient 
altitude so that the parachute-based recovery system will be effective. RUPC is 
intended for ballistic reentry, water landing, and retrieval by helicopter. Although 
the nominal splashdowns will be targeted to occur within aircraft range of KSC, 
abort via retum-to-Earth elsewhere is always possible within less than one 
revolution because of the high availability of alternative sea landing sites along the 
ground track. 


Performance Characteristics 


The following capabilities are based upon injection into an 80 by 220 nmi initial 
orbit at 28.5° inclination by the HR Titan IIS launch vehicle. The RUPC system has 
the on board capability to circularize, rendezvous, and berth with SSF, and 
subsequently perform the deorbit bum. 
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TABLE 3.3.3.13-1.- SYSTEM SUMMARY - RUPC 


RUPC 

Performance Summary and Specifications 

Type 

Ballistic capsule 

GLOW (Capsule* Adapter) 

12,000 lbs 

Pressurized volume 

**** f{3 

Crew 

6 persons 

Cargo 

1,000 lbs 
7 x 4 x 4-ft 


same as up 

On-orbit time 

5 days 

On-orbit propulsion 

1,080 ft/s 

Configuration 

Biconic 

Size 

14.5-ft dia. 
15-ft long 

Launch vehicle 

Titan IIS 


Attribute Values 

The following are attribute data to be used in evaluating the RUPC system. 

a. Funding Profile Summary - The costs in Table 3.3.3.13-2 are in millions of 1992 
dollars and are based on a 20-year program, after appropriate learning curves and 
quantity rate reductions. 


TABLE 3.3.3.13-2.- SYSTEM COST SUMMARY - RUPC 



Cost (1992 MS) 

DDT&E 

1425 

N/R Production 

145 

Facilities 

O&C Mods 

3 

First flight article 

117 

Recurring 

Production 

66 

Integration and Ops 

51 

P 3 DI 

0 


* Per unit, assuming replacement of adapter and LES after each launch, and 
replacement of capsule after seven flights. 
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Development is assumed to begin phase C/D in FY95, with an IOC of FYOO, as 
shown in Fig. 3.3.3.13-2. 
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Figure 3.3.3.13-2.- Development schedule. 


b. Probability of Mission Success.- The launch vehicle (see Titan family, section 
3.3.3.6, HR Titan IIS) contributes approximately two-thirds of the PMS for the 
system, while the RUPC only contributes the component for orbit 
circularization to this attribute. However, for the generic assessments made by 
this study, the unreliability for this OMS is taken to be the same as that for 
booster propulsion systems, which is overly conservative because of the 
multiple propellant tanks, valves, and plumbing routes that are embedded in 
the RUPC design. Because this system must also be used to provide the life- 
critical function of deorbit, with no other recourse, it is already designed to be of 
extremely high reliability. 

c. Human Safety - The LES system provides escape from the relatively benign 
environment of Titan failure modes (hypergolic propellants burning rather 
than exploding when free together, compared to the possibility of a major 
explosion of hydrogen or hydrocarbon /LOX launch vehicles). RUPC also has 
the capability to survive or escape the potential explosion of one of the small 
strap-on solids, although the hazard risk is small because these solid rockets are 
the very high reliability monolithic grain configuration, are located 60-ft from 
the capsule, and sized so that each has a total propellant load only 2 percent of 
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one Space Shuttle SRB. The LES provides uninterrupted escape capability from 
the launch pad ("0, 0" conditions) through max-Q, solids firings, and second 
stage ignition - after which it is jettisoned. 

d. Architecture Cost Risk - The RUPC is a new system. However, all subsystems 
derive from components and/or technologies already developed or currently 
under development for other flight programs. In addition, the design is 
compartmentalized so that multiple vendors are available for most subsystems, 
with the exception of contract integrator. The capsule, LES, and adapter could be 
supplied by different sources, and integrated at KSC or another appropriate 
facility. Because of clean interfaces, the lack of system complexity, and the 
planned retirement of vehicles on a regular basis, this remains the case even for 
rebuilds. Maintaining the competitive climate is part of the vehicle design 
philosophy. The ratings of RUPC for Technical Challenge were 8 for non- 
recurring development, 6 for production, and 3 for operations. The Program 
Immaturity index was rated as 7. 

e. Launch Schedule Confidence - The RUPC human system utilization includes 
several phases: flight mission (launch, on orbit operations, deorbit /landing), 
post-landing recovery, refurbishment, reassembly, fuel and stack, and pad 
operations, as delineated in Figure 3.3.3.13-3. Also included is a planned 
contingency phase to provide margin in the processing flow. Post-landing 
includes the helicopter acquisition of the capsule, transportation to the KSC 
hazardous processing facility (HPF) to purge RCS propulsion, and then 
movement to the O&C building. There the capsule is disassembled, then 
refurbished and tested by multiple teams operating in parallel, with some tasks 
accomplished on a double-shift schedule. Upon completion of reassembly and 
functional verification tests, the capsule is transported to a suitable HPF (e.g., 
SAEF) for mating to the waiting adapter and LES. After fueling the capsule RCS 
and mate and checkout of the units, the system is transported to the pad for 
stacking on the log- viewer (LV). 

Up to three flight RUPC’s are refurbished in parallel using a single Servicing 
Stand in the Operations and Checkout Building at KSC. Less than 45 calendar 
days are required to ready a capsule for next launch. With a fleet of three RUPC 
systems, allowing for recovery times, adapter plus LES mate, and pad processing, 
the HR Titan IIS/RUPC could support up to 12 human flights per year. 

f. Environment.- The RUPC does not affect the Earth's environment. The Titan- 
IIS launch vehicle is covered in section 3 . 33 . 7 . 
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Figure 3.3.3.13-3 - RUPC processing flow. 
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3.3.3.14 Cargo Return Vehide (CRV) and Logistics Return Vehicle (LRV) Systems 
System Description 

a. History - The original concept of a CRV was developed by NASA/MSFC and 
General Dynamics Space Systems Division (GDSS) during the STIS. There were 
three studies performed. The first was for a CRV for Space Station logistics, 
which began in mid-1989. The driving requirements then included a minimum 
return capability of one PLM of 40 000 lbs with dry land recovery. This CRV was 
baselined to operate in concurrence with the Orbital Maneuvering Vehicle 
(OMV), but could also dock directly to the SSF with appropriate modifications. 

The second study was performed in late 1991. This study incorporated SSF 
restructuring and focused on design of a CRV that would be carried by a NLS. 
The result was a cargo delivery and return vehicle that accommodated a 16 klb 
mini-PLM and was renamed the LRV. With an NLS-1 and CTV available at 
KSC, three LRV's can be launched together at a time. The third study examined 
alternative CRV sizes and recovery modes, using previous studies as references. 

The CRV concept selected for this study is the early CRV design (1989) and the 
LRV concept is from the second study. 

b. Configurations.- The CRV system is designed around a 15 by 25 foot cylindrical 
cargo volume of the PLM. The result is a lifting body configuration with two 
small aft canards and parafoil recovery system. Access to the payload area is 
possible through two payload bay doors operating much like those on the Space 
Shuttle. Figure 3.3.3.14-1 illustrates the CRV configuration. 

Major subsystems of the CRV include its structure, tanks and landing gears, 
orbital maneuvering and attitude control systems, recovery, avionics, power, 
and thermal control systems. Total CRV dry weight amounts to just over 
34 400 lbs. The CRV is designed for lift-off with 40 000 lbs of payload and landing 
with about 72 800 lbs of combined CRV and payload weight. 

At almost 80 000 lbs lift-off weight, the CRV and its payload requires a heavy lift 
booster capacity. For this study the CRV is integrated with the NLS-1 in 
Architecture 4, and with the MLS-HL in Architectures 5, 6 and 7. 
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Figure 3.3.3.14-1.- CRV baseline configuration. 


The LRV system is designed to deliver and return the Mini-Pressurized Logistics 
Module (MPLM) of 16 000 lbs. The basic cargo volume is 15 ft in both length and 
diameter. The system has limited maneuverability and uses a skirt extension in 
the aft section for trim stability. Access to the payload area is possible through 
the back of the LRV where the MPLM can be seen exposed. Figure 3.3.3.14-2 
illustrates the LRV configuration. 

The LRV is also intended to deliver unpressurized logistics carriers, SSF 
propulsion modules, and returning CTV's. The LRV could be optimized to 
include an integral PLM, thus reducing some LRV/cargo structural redundancy. 
Both the current configuration and future derivatives could be designed to 
remain at the SSF (docked at a node) for the mission duration of its payload. 

Major subsystems of the LRV include its structure, orbital maneuvering and 
attitude control systems, drogue parachute and parafoil recovery systems, and 
avionics, power, and aeroshield thermal control systems. The total LRV system, 
including the MPLM, weighs about 31 400 lbs. 

For this study, the LRV is integrated with the MLS-HL and RPCmin in 
Architecture 7, and with the Titan IV/CTF in Architectures 16 and 17. 
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Figure 3.3.3.14-2 - LRV baseline configuration. 


c. Facilities.- Since the CRV’s main mission will be to support the SSF, the CRV 
will only operate out of KSC. Regardless of which new booster will be selected 
to launch it, the CRV will ride as a payload during launch. As such, the CRV-to- 
booster integration and launch facilities are accounted for as part of the booster 
system, namely the NLS-1 and MLS-HL. There is only one facility required by 
and dedicated to the CRV system, the CRV Processing Facility. This is where 
pre- and post-flight maintenance, system tests, and verifications of the CRV are 
carried out. In addition, payload installation and removal are also done here. 

The LRV system utilizes a decommissioning facility at the landing site in south 
Texas and a refurbishment and processing facility at the launch site. Integration 
into the booster occurs in the payload processing facility or vehicle assembly 
building depending upon the launch system. In this study, the boosters for the 
LRV are the MLS-HL and the Titan IV/CTF. All launch and mission operations 
support facilities are shared with those of the boosters. 
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d. Operational Flow - Figure 3.3.3.14-3 shows the CRV nominal operations flow at 
KSC. The facilities called out in this section are generic. Their names describe 
their functions only, and they are not necessarily associated with any specific 
launch system. 

The CRV will be processed together with its payloads in the CRV Processing 
Facility. This is where system decommissioning, payload removal (for return 
missions), and various system maintenance, verifications, and tests are done. 
The new payload will be integrated into the CRV in this same facility. As this 
phase is completed, the CRV and its payload will become a single payload from 
the launch vehicle's perspective. They will then be transported to the Booster 
Integration Facility (for new launch concepts with integrate-transfer-launch, ITL, 
philosophy), where integration to the launch booster is performed. The vehicle 
stack will then be moved to the launch pad for launch. 

At the end of its orbital mission the CRV lands at KSC via parafoil. It is then 
transported to the CRV Processing Facility where the cargo is separated and the 
ground processing flow is repeated. 


Safing 

Recoveiy and Transport 
to CRV Proc Facility 

Decommission] ng 

Payload Removal 

CRV Maintenance 

Engine Maintenance 

Other Maintenance and 
System Verification 

Integration Tests 

Payload Installation 

Transport to Booster 
Integration Facility 

CRV /Booster Integration* 

Move to Pad 

Launch Readiness 
Verification 


■ 














- 

■ 














■ 









































* 








m 


H 


m 



































■ 














■ 















■ 















Hi 















- 


5 

.10 

15 

20 

25 

30 

35 

40 

45 

50 

55 

60 

65 

1 

70 


* Time For Integration Dependent On Booster Chosen SHIFTS 

Figure 3.3.3.14-3.- CRV ground-processing flow. 
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Figure 3.3.3.14-4 shows the LRV nominal operational flow at KSC. The launch 
vehicle here was assumed to be configured with a main core with ASRM, but 
any appropriate booster can be substituted with associated launch vehicle 
processing. 

In general, the LRV will be processed together with its payloads (mainly the 
MPLM) in the refurbishment and processing facility. As this phase is completed, 
the LRV/cargo will become a single payload from the launch vehicle's 
perspective. They will then both be transported to the Vehicle Assembly 
Building (for new launch concepts with integrate-transfer-launch, ITL, and 
philosophy), where integration to the launch booster is performed. The vehicle 
stack will then be moved to the launch pad for launch. 

For launching on existing systems such as Titan IV, the LRV/MPLM and the 
CTF system will be mated to the booster on pad in much the same fashion as 
current Titan IV payloads. 

At the end of the orbital mission the LRV lands in south Texas via parafoil. 
CH-53 helicopters will retrieve the LRV to a facility near the landing site, where 
the LRV is decommissioned. The cargo is transported on a C-5 to KSC for 
processing and analysis, while the LRV is ferried to the refurbishment center on 
a barge via the Intercoastal Waterway. The system is then prepared for its next 
mission. 


Performance Characteristics 


The CRV has been designed to deliver and return with 40 000 lbs and at a total 
landed weight of 72 800 lbs. It can carry approximately 7770 lbs of usable propellant 
for orbital maneuvering including rendezvous, proximity operations, attitude 
control, and deorbit bums. Table 3.3.3.14-1 shows the performance and physical 
characteristics of the CRV and LRV used in this study. 

The LRV has been designed to land with 16 000 lbs and at a total landed weight of 
29 000 lbs. It can carry approximately 2400 lbs of usable propellant for orbital 
maneuvering, primarily for attitude control and deorbit burns. 
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Figure 3.3.3.14-4.- LRV ground-processing flow. 


TABLE 3.3.3.14-1.- CRY AND LRV PERFORMANCE CHARACTERISTICS 



CRV 

LRV 

GLOW (lbs) 

82,924 

31,400 

Press. Volume (ft3) 

0 

0 

Unpress. Volume (ft3) 

4418 

2651 

Cargo Envelope (lxd) 

25x15 

15x15 

Cargo Capacity (lbs): 



220 nmi circ, 28.5° 

40,666 

16,000 

Return Capacity (lbs) 

40,000 

16,000 

Crew Capability (#) 

0 

0 

Launch Site Limits 

East Coast 

East Coast 
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Attribute Values 


a. Funding Profile Summary - The development and facility costs for both the 
CRV and LRV are tabulated in Table 3.3.3.14-2. The LRV landing site facilities 
are included in the "Other Facilities" category. Cost per flight (CPF) for the two 
concepts are shown at various flight rates per year in Table 3.3.3.14-3. CPF 
values are also shown for the CRV /booster and LRV/booster combinations used 
in the architectures. Total architecture life cycle costs and funding profiles are 
specific to individual architectures. These can be found in the architecture 
results sections. 

TABLE 3.3.3.14-2.- CRV AND LRV COST ESTIMATES 


All Values in $92M 

CRV 

LRV 

DDT&E 

1,661 

580 

N/RProd 

249 

193 

P3I 

0 

0 

Facilities: 


•n , 1 

Processing Facility 

10 

29 

Other Facilities 

0 

26 


TABLE 3.3.3.14-3.- CRV AND LRV COSTS PER FLIGHT 



Flights Per Year 

Costs Per Flight ($92M) 

2 

4 

6 

8 

10 

12 








CRV 

80.6 

41.5 

28.3 

21.6 

17.5 

14.8 

CRV/NLS-1 

248.6 

205.5 

189.3 

179.6 

173.5 

167.8 

CRV/MLS-HL 

227.6 

188.5 

175.3 

168.6 

163.5 

160.8 








LRV 

69.2 

35.4 

24.0 

18.2 

14.8 

12.4 

LRV/CTF/Titan IV 

413.2 

310.4 

265.0 

238.2 

219.8 

206.4 


The CRV development schedule is shown in Figure 3.3.3.14-5. It includes an 
extensive technology development program for large steerable parafoils, 
advanced TPS, and autonomous rendezvous and docking capabilities. The 
major schedule driver is the parafoil technology development which includes 
several drop tests of an 80 klb recovery system before critical design review 
(CDR). The CRV development results in an IOC approximately 8 years after 
start of Phase A. 
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Figure 3.3.3.14-5 - CRV development schedule. 


The LRV development schedule is shown in Figure 3.3.3.14-6. The LRV 
requires less technology development than the CRV because of its smaller size 
and restricted operational capability. In fact, the technologies are enhancing, not 
enabling, and there are state-of-the-art fallbacks for all systems. A parafoil 
recovery system tailored for a 27 klb landed weight is significantly less aggressive 
than the CRV requirement (80 klb). In addition, the LRV does not perform 
orbital maneuvering other than attitude control and deorbit. Rendezvous and 
docking is performed by another system (e.g., cargo transfer vehicle). The LRV 
has an initial operational capability less than 8 years after Phase A start. The 
LRV development schedule could be condensed, however, the earliest need date 
for this study is the year 2000. 
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Figure 3.3.3.14-6 - LRV development schedule. 


b. Probabilty of Mission Success - The CRV performs the same function 
(rendezvous and docking) as a CTV during ascent with a similar orbital 
maneuvering system, therefore the PMS scores are the same for CRV/NLS-1 
and CTV/NLS-1. The LRV is passive throughout the ascent and rendezvous 
phases and therefore requires a CTF to get to SSF. Further description of how 
these numbers were derived is included in section 3.2.4. 

c Human Safety - The CRV and LRV carry only untended cargos in the 

architectures currently being examined in this study and, therefore, do not have 
corresponding safety scores. 
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TABLE 3.3.3.14-4.- PMS FOR CRY AND LRV MISSIONS 


System 

PMS 

CRV: 


CRV/NLS-1 

0.9308 

CRV/MLS-HL 

0.9543 



LRV: 


LRV/CTF/Titan IV 

0.9307 


d. Architecture Cost Risk.- Table 3.3.3.14-5 shows the risk scores for the CRV and 
LRV. Section 3.2.5 describes the level of risk that these numbers represent. Note 
that a technical challenge of 5 or less is still within state-of-the-art. However, 
since there has not been a significant amount of detailed design work on either 
concept, the program immaturity was ranked high. The booster risk scores are 
discussed under the specific booster section. 


TABLE 3.3.3.14-5.- RISK SUB ATTRIBUTE SCORES FOR CRV AND LRV 



Technical Challenge Subattribute 

Prgm. Immaturity 
Subattribute 

Non-Recurring 

Production 

Operations 

CRV 

4 

3 

3 

7 

LRV 

3 

3 

2 

7 


e. Launch Schedule Confidence - As with ACR, two of the three subattributes for 
LSC were based on system values or scores. One of these, schedule compression 
was calculated based on the operations data given earlier in this section. Its 
value represents the ratio of nominal processing time to the shortest processing 
time (maximum compression of the critical path). The other, percent of flights 
with delays, was calculated based upon UMA's for the system (see section 3.2.6). 
Table 3.3.3.14-6 shows the above two subattribute scores for CRV and LRV. Both 
of the subattribute values were subsequently used with architecture-particular, 
flight-rate data to roll up the architecture level values. The schedule margin 
subattribute score is architecture specific and is described in sections 3.3.5 
through 3.3.11. 
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TABLE 3.3.3.14-6.- LAUNCH SCHEDULE CONFIDENCE SUBATTRIBUTE SCORES 

FOR CRY AND LRV 


Schedule 

Confidence 

Attribute 

Schedule Compression Subattribute 

% Flights With 
Delay 

Subasttribute 

Nominal 
Processing 
Time (Days) 

Compressed 
Processing 
Time (Days) 

Ratio: 
Nominal to 
Compressed 

CRV 

42 

13 

0.310 

15.95 

LRV 

106 

33 

0.311 

5.61 


f. Environment - The CRV and LRV have no significant atmospheric effluents. 
However the booster used to transport them will contribute to the Environ- 
mental attribute scores. NLS-1, MLS-HL, and Titan IV effluents and 
environment scores are discussed in sections 3. 3.3.9, 3.3.3.10, and 3.3.3.7, 
respectively. 
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3.3.3.15 Single-Stage-To-Orbit (Vertical Take-Off and Horizontal Landing (VTOHL) 
Rocket) 

System Description 

The SSTO- VTOHL is a reusable space transportation system concept studied as part 
of a DOD contract (Final Report #NA-91-277) by Rockwell International. The 
concept concluded with VTOHL as the preferred configuration. Design goals of the 
SSTO-VTOHL are: fail safe operation with engine-out capability during all portions 
of powered flight; flight crew escape during ascent and entry; simplified vehicle 
design to allow for 7-day turn around with 350 man-days effort; on-orbit 
maneuvering velocity change (delta-V) of 600 ft/ sec in addition to the reentry delta- 
V; cabin pressure of 14.7 psia; and launch-rate surge to double the routine launch 
rate and maintain that rate for 30 days. Two major modifications were made to 
these goals. The first was to design the SSTO-VTOHL payload bay volume so that it 
could deliver a large portion of the payloads in its lift capacity. The second was to 
stipulate that the vehicle must be able to fly in a piloted and unpiloted mode. 



Figure 3.3-3.15-1.- The HTS rocket powered SSTO system is Rockwell’s 
vertical take-off, horizontal landing concept. 


Performance Characteristics 


The SSTO-VTOHL reusable space transport is designed to launch a crew of two and a 
payload of 10 000 lbs to polar orbit. In an easterly inclination, payload capacity is 
17 700 lbs to the SSF orbit. The 600 fps AV provides for delivery and return of the 
17 700 lbs to or from SSF. Main propulsion is provided by an aerospike engine with 
a modular design and the nozzle performance supported by computational fluid 
dynamics analysis. Thrust vector control is provided by differential throttling and 
gas injection. Triple-point LOX and LH 2 is required to provide adequate propellant 
density to meet performance parameters. A standard piloted mission allows for 
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96 man-hours on orbit with a 96 man-hour contingency. SSTO-VTOHL's payload 
volume is 3000 cubic feet, it has a maximum cross-range of 1150 nmi, and an 
approximate landing speed of 180 kts resulting in a roll out of 5900 ft after 
touchdown. 


TABLE 3.3.3.15-1.- SSTO-VTOHL PERFORMANCE CHARACTERISTICS 


Inclination 

Apogee X Perigee 

Payload 

(deg) 

(nmi) 

(klbs) 

28.5 

160 x 160 

17.1 

28.5 

220 x 220 

15.0 

90.0 

100 x 100 

10.0 


a. Abort Modes.- The SSTO-VTOHL has a built-in, robust abort capability. It has 
engine-out capability from lift off. Selected vehicle crossrange allows abort once- 
around with return to the launch site for all inclinations. Abort modes and 
their limitations are: 

• RTLS - Available during launch when AV is less than 10 900 fps. 

• AOA - Opportunities are available much earlier than the last RTLS option. 
Vehicle has a 1050 nmi cross range required to support AOA for polar 
launches. 

• ATO - With full lift-off-thrust capability available throughout the flight 
phase, SSTO-VTOHL can perform ATO over a large portion of the flight 
phase. 

b. Operational Facilities.- SSTO-VTOHL has five main facilities: Launch Pad, 
Landing Site, Vehicle Maintenance Facility (VMF), LCC, CPF, and GSE 
Maintenance Facility. The VMF provides adequate space for performing 
between-flight maintenance on four operational vehicles and has three unique 
maintenance cells: a vehicle maintenance cell (VMC), a logistics support cell, 
and a vehicle isolation cell (VIC). Specialized work areas for pre- and post-flight 
maintenance as well as cargo module loading are performed in the VIC. Spare 
parts are stored in and distributed from the logistics support cell. Any "all clear" 
maintenance or hazardous operations are performed in the VIC, allowing 
normal processing of other vehicles to continue unabated. An operations flow 
schematic is shown in Figure 3.3.3.15-2. SSTO-VTOHL's IOC for the HTS is in 
2000 to reflect the early goals of this program. 
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Figure 3.3.3-15-2.- SSTO-VTOHL operations flow schematic. 


Attribute Values. 

System input data related to each attribute, as well as system-specific attribute values 
are discussed below. In most cases, system data is modified by flight rate or cost 
associated with the particular architecture and/or "If’ being evaluated. However, 
some useful observations can be made at the system attribute level. 

a. Human Safety.- Relevant system data for human safety consists of system 
characteristics that enable the crew to detach or escape from the main body of the 
system during ascent in the event of a mission failure. The SSTO-VTOHL does 
offer ejection seats for flight crew escape during ascent and descent operations. 

In addition, several abort options (described earlier) exist and can be used in the 
event of a non-catastrophic engine failure. They are: RTLS, AOA, and ATO. If 
an ATO is executed, it is possible that the mission will be a success. Another 
salient feature is that the crew module is in the same element as the liquid 
engines and main propellant tanks. 

b. Funding Profile.- Cost information provided to the HTS included the cost of 
new facilities, new vehicles, variable and fixed costs per flight for each flight 
element, and launch and flight operations. In addition, spread factors for each 
cost item were provided, identifying how much of the total cost was spent in the 
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years proceeding the need or flight date. Table 3.3.3.15-2 presents a summary of 
this data. 


TABLE 3.3.3.15-2.- SSTO-VTOHL FUNDING PROFILE INPUT DATA 


COST BREAKDOWN 
CATEGORIES 

TOTAL 

ORTFU 

COST 

($M) 


RATE 

CURVE 

(%) 

COST 

PER 

FLT 

($M) 

COST 

PER 

YEAR 

($M) 

Y 

-5 

(%) 

i 



1 

FLTI 

OC 

YR 

(%) 

NON-RECURRING 







HI 


HI 



RDT&E 

2705 





15 

in 



10 


PRODUCTION 

0 











P3I 

13.5/YR 











FACILITIES 

630 






E3 

30 

EH 

15 


RECURRING 









_ 



NEW 








■HI 




VEHICLE (new) 

579 

100 

100 




Hi 

ta 

BS1 

25 

5 

PLUG NOZZLE ENG 
(new) 

74 

90 

90 



■ 

■ 

■ 

10 

85 

5 

FLIGHT TO FLIGHT 












REFURBISHMENT 




1.4 

115.0 






100 

LAUNCH OPERATIONS 

i 



! 0.5 

92.4 






100 

FLIGHT OPERATIONS 




0.1 

25.9 






100 

PROG MGMNT 





35.2 

- 

— — 


■ 


100 


c Probability of Mission Success.- A system description and flight profile contains 
the required input information for this attribute. In summary, the SSTO- 
VTOHL has one liquid propulsion stage, 14 liquid engine modules (with engine- 
out capability from lift off). 

d. Architecture Cost Risk - Two of three subordinate attribute values for ACR are 
Technical Challenge and Program Immaturity. The NTT placed SSTO-VTOHL at 
a scale rating of 9 (Non-recurring), 6 (Production) and 9 (Operations) for 
Technical Challenge and an 8 for Program Immaturity, resulting in a value of 
59.9, 12.9, and 59.9, respectively, for Technical Challenge in "IP C, and a 35.9 for 
Program Immaturity (see section 3.2.5). The third component. Number of New 
Systems, is an architecture-level value; SSTO-VTOHL’s contribution to this 
parameter is 1. 

e. Launch Schedule Confidence.- As in ACR, there are three subordinate attribute 
values for LSC: Schedule Compression, Schedule Margin, and Delays (due to 
unscheduled maintenance activities). Schedule Compression and Delays are 
architecture independent, while Schedule Margin is architecture dependent 
since its values are a function of annual flight rates and available facilities and 
Orbiters. SSTO-VTOHL's Schedule Compression values are nominal cycle time 


3.3-120 


Rev. E 





















































- 13.3 days, compressed cycle time - 13.3 days, and compression ratio - 1.0. It is 
estimated that SSTO-VTOHL will experience delays in 9.7 percent of its launch 
attempts. 

f. Environmental Impact - The SSTO-VTOHL uses liquid hydrogen and liquid 
oxygen as its only propellants. Its propellant load includes oxygen - 
832.029 klbm, and hydrogen - 139.671 klbm. Using the given propellant weights, 
major effluent constituents were determined and are shown in Table 3.3.3.15-3. 
These values are based on equilibrium, non-afterburning calculations. 


TABLE 3.3.3.15-3.- EFFLUENT DATA FOR SSTO-VTOHL 


Exhaust 

Space Shuttle 

Product 

(klbm) 

CO 

0.0 

CO 2 

0.0 

H2 

32.8 

H20 

918.5 

HC1 

0.0 

n 2 

0.0 

OH 

0.0 

H 

0.0 

AI 2 O 3 

0.0 
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3.3.3.16 National-Aerospace-Plane-Derived Vehicle (NDV) 

The NDV is an air breathing SSTO vehicle that takes off and lands horizontally 
(Figure 3.3.3.16-1). Its hydrogen-fueled engines accelerate it from the standstill 
through hypersonic speeds to orbital velocities. As its name implies, NDV makes 
full use of technologies developed in the NASP program. Its current design 
requirements include commercial runway (12 000 ft) take off and landing (not 
necessarily the one from which it left); acceleration to orbital velocity in the 
atmosphere; coast-to-orbit apogee; orbit circularization with a reaction control 
system; and payload deployment, recovery, servicing, and/or repair. Standard 
mission length is 24 hours or less, but can be extended to 72 hours with kits. The 
NDV's design reference mission is either delivery of 10 000 lb payload to or from a 
100 nm circular orbit at an inclination of 90°, or delivery and return of 20 klbs to and 
from SSF (220 nm circular at 28°) from KSC. With its unique ascent cross range, the 
NDV can deliver approximately the same payload to a 0° inclined orbit as it can to a 
90° one from a mid-latitude operational base. Extensive ascent and decent cross 
range greatly facilitates operational flexibility, extends the launch widow, and 
enables a full-envelope-abort capability. Payload capacity as a function of inclination 
and altitude is presented in Table 3.3.3.16-1. 



Figure 3.3.3.16-1- Representative NDV concept. 
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TABLE 3.3.3.16-1.- NDV PERFORMANCE CHARACTERISTICS 


Inclination 

(deg) 

Apogee x Perigee 
(nmi) 

Payload 

(klbs) 

Comments 

28.5 

100 x 100 

26.5 


28.5 

150 x 150 

25.5 


28.5 

200 x 200 

23.5 


28.5 

250 x 250 

20.5 


28.5 

262 x 262 

18.2 

SSF Direct Access 

28.5 

300 x 300 

17.5 


57.0 

180 x 180 

18.0 


57.0 

324 x 324 

9.5 


90.0 

100 x 100 

10.0 

Design Point 

90.0 

150 x 150 

9.0 


98.7 

300 x 300 

1.0 

Goes to zero at 340 nmi 


Designed for reliable, low cost, "airplane-like" operations, the NDV can be quickly 
turned around for frequent flights. Designed-in supportability, extensive built-in 
diagnostics, 200 man-hours per mission scheduled maintenance, and simplified 
loading and unloading of containerized payloads in less than 4 hours enable routine 
flight-to-flight process times of less than 3 days. The payload containerization 
concept uses standard interfaces between the container and the vehicle for flexible 
operations and versatility. Payload integration flexibilty is maintained by the 
internal design of the container. Standard payload services provided by the vehicle 
can be augmented with a wide range of kits that can be installed in the container. 

The weight of the standard container and services are charged against the vehicle, 
while the weight of additional special services and kits is charged against the 
payload. Integration of the payload into the container is performed off-line and is 
never permitted to delay the vehicle. Also, since the vehicle flight characteristics 
are designed to accommodate a payload center-of-gravity located anywhere within a 
volume concentric to the container envelope, with dimensions aproximately 
50 percent of the container, they can be rapidly switched to fly on another vehicle in 
the advent of a problem with the originally scheduled vehicle. Loading the payload 
into the vehicle can be handled in a clean room environment and the payload 
operators can have access until shortly before launch, although last minute access is 
not encouraged. 

a. Mission Abort Options - The NDV has two basic abort options during the air- 
breathing portion of its trajectory - return to any runway with adequate length 
or crew module separation. Due to the nature of the NDV propulsion system, 
failures resulting in significant vehicle damage are considered to be remote. 

This feature, coupled with the engine design, which has eight air passageways 
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support by four feed systems, enables the NDV to continue flight under 
diminished power, enabling it to reach any of several airports within its range. 
The loss of a propellant feed system or air passageway basically eliminates its 
ability to achieve orbit. In the event that serious vehicle damage has occurred, 
which may lead to loss of the vehicle, the crew module can be jettisoned. This 
option is available to the crew throughout the NDV mission profile. 

Following shutdown of its air-breathing engines, the NDV requires two rocket 
bums to achieve orbit. The first bum inserts the vehicle into a transfer orbit and 
the second is the circularization burn in its destination orbit. Engine-out 
capability is not available during the first burn but is an option for the 
circularization maneuver. It is assumed that the NDV OMS system consists of 
two engines, does not have a dual OMS tank system, and therefore does not 
have cross-feed. These assumptions were made due to the unavailability of 
OMS schematics. 

b. Operational Facilities.- An overview of a typical NDV operations site is shown 
in Figure 3.3.3.16-2. Operational facilities include a 12 kft normal runway, a 
cryogenic hydrogen or oxygen propellant loading station, a fuel conditioning 
plant to produce densified, or slush, hydrogen (SH 2 >, a maintenance building, a 
payload loading and unloading facility, and a mission planning center. 

c. NDV Attribute Data.- System input data related to each attribute, as well as 
system specific attribute values, are discussed below. In most cases, system data 
is modified by flight rate or cost associated with the particular architecture 
and/or "If" being evaluated. However, some useful observations can be made at 
the system attribute level. These will be discussed following the presentation of 
the NDV system data. 

(1) Human Safety . Relevant system data for human safety consists of system 
characteristics that enable the crew to detach or escape from the main body 
of the system during ascent in the event of a mission failure. The NDV's 
air-breathing propulsion system, discussed above under Mission Abort 
Options, provides the capability to return to any capable airport under 
powered flight for most propulsion failures. For situations resulting in 
significant vehicle damage or loss of control, the crew module can be 
separated from the main body of the NDV. This protects the crew until the 
module is returned to an altitude and velocity at which the crew can safely 
eject from the module for parachute recovery. Other salient features 
include having the crew module at the forward end of the vehicle, ahead of 
the main hydrogen tank, and having limited oxygen on board for OMS and 
RCS engine operation. Probable crew loss events by mission phase are 
presented as part of the "PMS" discussion. 
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Figure 3.3.3.16-2 - NDV fixed-base-of-operations concept overview. 

(2) Funding Profile . This information is from the NDV Operations and 
Supportability Assessment completed by General Dynamics' Fort Worth 
Division and presented as Task H8 Final Review on May 16, 1991. The 
baseline total cost to bring NDV to operational status is $16.7 B in 1986 
dollars. This is further defined as $8.9 B86 for DDT&E, $5.4 B86 for procure- 
ment, and $2.5 B86 for Operations and Support. Its average cost per flight 
for a 4-vehicle fleet flying 24 flights-per-year, based on a "Shuttle Down" 
analysis, is predicted to be $14 M86. Based on discussions between Dan 
Eimers of the GDSS Division in San Diego and Dr. Toten of their Fort 
Worth Division, values for the HTS cost input sheet were developed from 
existing program information. These are presented in Table 3.3.3.16-2. It 
should be noted that since NDV is a fully reusable vehicle with airline-like 
operations, all per-flight costs are expended in the year of the flight. 
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TABLE 3.3.3.16-2.- NDV ACQUISITION FUNDING PROFILE INPUT DATA 


NDV Cost Breakdown 

Total 
Or TFU 
Cost 
($M92) 

n 

Y-6 

(%) 

K&fl 

■ 

Y-3 

(%) 

Y-2 

(%) 

Y-l 

(%> 

IOC 

Yr 

(%) 

Non-Rrecurring 










RDT&E 

12517 

8 

16 

23 

20 

16 

10 

7 


Production 










P3I (Annual After IOC) 










Facilities 










Development 

243 

8 

16 

22 

20 

16 

10 

6 

2 

Production 

120 

8 

16 

22 

20 

16 

10 

6 

2 

Operational 

120 

8 

16 

22 

20 

16 

10 

6 

2 

Recurring 

Unit 

LC 

RC 


B3I 

Y-3 

■29 

■SI 



Cost 

(%) 

(%> 





1 







■fell 

(%) 

(%) 

■HI 


Protoflight #1 

1120 

100 

100 


15 

55 

25 

5 


Protoflight #2 

1030 

100 

100 


15 

55 

25 

5 


Right Unit #1 

2191 

100 

100 



38 

58 

14 ! 


Flight Unit #2 

1961 

100 

100 



38 

58 

14 






VAR 

Fixed 









CPF 

CPY 




EU533 

Launch/Flight OPS 




7 

186 




I 


(3) Probability of Mission Success . The mission success tree and propulsion 
systems descriptions are required to quantify the NDV PMS. Referring to 
Figure 3.3.3.16-3, the NDV ascent trajectory has been divided into six 



Figure 3.3.3.16-3 - NDV mission success tree. 























































































distinct flight phases, (1) rollout up to ramjet mode, (2) ramjet mode, (3) 
scramjet mode through engine cutoff, (4) orbit insertion, (5) coast, and (6) 
orbit circularization. During the first three ascent phases, propulsion is 
provided by the air-breathing engines, which consist of eight flow paths 
supported by four propellant pumps drawing from one propellant tank. 

For purposes of our PMS process, the NDV has four air-breathing engines 
and one liquid propulsion stage for the OMS/RCS system. Since all 
engines are required for the NDV to achieve flight conditions necessary for 
the OMS/RCS to successfully provide orbit insertion and circularization 
maneuvers, the air-breathing portion of the NDV ascent profile does not 
have engine-out capability. 

Without benefit of an OMS/RCS schematic or description, the NDV is 
assumed to have a two-engine system with a single set of tanks and feed 
system. Both engines are required for the insertion bum while only one is 
required to circularize. Based on this information, the equations defining 
NDV PMS are as follows: 


Flight Phases 1-3 
Rpi-3 = (Ra/b 4 )^ 1 ! 3) •Rad / 6) 

Flight Phase 4 

Rp4 = (Roms 2 ) # R S •Ra^ 1 / 6) 

Flight Phase 5 

Rp5 = Ratt/6) 

Flight Phase 6 

Rp6 = [ (Roms 2 ) +2 • (1 -Roms) • Roms] • Rs * Ra^ / 6), 

where Ra/b is the air-breathing NDV engine reliability, R s is the NDV air- 
breathing and OMS engine propulsion stage reliability, Ra is the avionics 
reliability, and Roms is the OMS engine reliability. Values for these terms 
and for the NDV, both by phase and cumulative through the ascent 
trajectory, are found in Table 3.3.3.16-3. The values in this table are 
somewhat higher than those used in the AET and in determining the 
probability of crew loss, due to an error in the exponent for Ra in equations 
1 through 4, above. Results used in the AET are based on R a having an 
exponent of 1 to 5, rather than 1 to 6. This error caused the final PMS value 
to be 0.96458 versus the 0.964595 shown below, resulting in a 0.00650691 
probable crew loss as opposed to 0.006583 shown in Table 3.3.3.16-3. These 


3.3-127 


Rev. E 


changes, plus a possible data-entry error in the crew loss rate in Phase 6 
(0.071 vs. 0.0763), gives an estimated number of flights between crew loss 
events of 153.7 versus the 151.9 in Table 3.3.3.16-3, or an error of 
approximately 1 percent. 

(4) Architecture Cost Risk . ACR is composed of three distinct subattribute 
values: Technical Challenge, Program Immaturity, and Number of New 
Systems. NDV's Technical Challenge attribute values are 10 for the non- 
recurring aspects, 10 for the production phase, and 9 during operations 
(based on the HTS NIT range of 7-10). Its Program Immaturity level is 
thought to be 10. Finally, it counts as one new system within an 
architecture. 


TABLE 3.3.3.16-3.- NDV PMS DATA 


NDV 

Reliability 

Values 

Ra/b 

0.9999 

Rs 

0.9847 

Ra 

0.9999 

Roms 

0.9977 



NDV PMS 

Phase 1 

Phase 2 

Phase 3 

Phase 4 

Phase 5 

Phase 6 

By Phase 

0.999850 

0.999850 

0.999850 

0.980159 

0.999983 

0.984678 

Cumulative 

0.999850 

0.999700 

0.999550 

0.979718 

0.979604 

0.964595 

Probable 
Crew Losses 







By Phase 

0.000019 

0.000025 

0.000025 

0.005343 

0.000001 

0.001169 

Cumulative 

0.000019 

0.000044 

0.000069 

0.005411 

0.005421 

0.006583 


(5) Launch Schedule Confidence . This attribute is also a combination of three 
subattributes: Schedule Margin, Schedule Compression, and Percentage of 
Flight Delays. Schedule Compression and Percentage of Flight Delays are 
system-dependent, while Schedule Margin is architecture-dependent. 

Since NDV operations are based on 7-day, 3-shift weeks, the nominal and 
compressed times are equal. The estimated number of Percentage of Flight 
Delays for NDV is 10.44. 
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(6) Environmental Impact . The NDV uses hydrogen as its ascent propellant, 
drawing in atmsopheric gases to provide oxygen for the combustion 
process. In reality, this will probably produce nitrogen oxides and other 
trace products in the exhaust stream, in addition to water vapor. However, 
due to the uncertainty of the engine concept and its true combustion 
characteristics, the HTS has opted to address only the impact of NDV's 
dominant exhaust product - water. The amount of exhaust product is 
determined by the vehicle propellant load. Specific design details such as 
inert weight, propellant load, and engine schematics are restricted access 
data. For evaluation purposes, the estimated hydrogen quantities on board 
the NDV are approximately 800 klbs. Based on a mixture ratio of 
6 to 1 (oxygen to hydrogen), and equilibrium combustion, the exhaust 
products consist of 5406.8 klbs of water and 193.2 klbs of hydrogen. 
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3.3.3.17 Advanced Manned Launch System (AMLS) 

System Description 

The AMLS (Figure 3.3.3.17-1) configuration and operational concept is a two-stage, 
fully reusable, launch vehicle defined by Langley Research Center and studied under 
contract by Rockwell International, Downey, CA. The AMLS has its first flight in 
2005 and is expected to fully replace Space Shuttle by 2010. The AMLS is comprised 
of three major elements: an untended reusable booster, a personnel reusable 
orbiter, and the Payload Containment System (PCS). The booster and orbiter are 
fueled with Liquid Oxygen(LC> 2 ) /Liquid Hydrogen (LH 2 ) propellants. All SSME- 
derivative engines on the orbiter and booster are ignited on the ground prior to lift 
off, with propellant transferred to the orbiter from the booster during first-stage 
operation. After separation, the booster returns to the launch site for horizontal 
landing while the orbiter with attached PCS continues on to the SSF or on-orbit 
mission. After its mission is complete, the orbiter returns to the launch site for 
horizontal landing. 


PAYLOAD BAY 



Figure 3.3.3.17-1- AMLS configuration. 


Performance Characteristics 

The design reference mission is to provide cargo transport of 40 k payload /logistics 
and to provide crew rotation of 10 personnel (2 flight crew and 8 passengers) to the 
SSF (220 nmi at 28° inclination). Additional capabilities allow it to support on-orbit 
servicing and repair missions. 
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Attribute Values 


a. Funding Profile - No information supplied at this time. 

b. Probability of Mission Success.- The AMLS has two liquid propulsion stages and 
five liquid engines, per stage, with engine-out capability, per the abort 
descriptions. The success tree is shown in Figure 3.3.3.17-2. Table 3.3.3.17-1 
illustrates the mission success probability by phase. 



Phase 

1 Stage 1 and 2 Ignition 

2 Stage 1 and 2 Burn 


Comments 

Five SSMEs per vehicle - parallel 
burn - one engine out in booster, 
orbiter, or both 

Engine out in each vehicle from lift 
off 


3 Staging Vehicle separation 

4 Booster Return to Dead stick return 

Launch Site 


5 Stage 2 Bum Phase Engine out from separation, if no 

previous failure 

6 Coast-to-Launch Apogee 

7 Orbit Circularization Two OMS engines, one can do job - 

dual tanks with cross-feed 


Figure 3.3.3.17-2.- AMLS success tree. 
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TABLE 3.3.3.17-1 AMLS MISSION FAILURES PER 100 MISSIONS 


Phase 

Losses Per 100 Missions 

Stage 1 and 2 Ignition 

0.6442 

Stage 1 and 2 Burn 

0.6442 

Staging 

0.0117 

Stage 2 Burn Phase 

0.2592 

Coast-to-Launch Apogee 

0.0117 

Orbit Circularization 

0.0117 

Total Per 100 Missions 

1.56 


Human Safety.- Relevant system data for human safety consists of system 
characteristics that enable the crew and passengers to detach or escape from the 
main body of the AMLS orbiter during ascent or descent in the event of a 
mission failure. The crew and passengers may escape from the AMLS by 
jettisoning the crew module from the main body of the AMLS orbiter. This 
action may be performed from the time the duct system on the access tower at 
the pad is no longer available to any time throughout the mission (except for a 
small portion of the return trajectory). Additional AMLS orbiter abort modes 
are available as described below: 

. Return to Launch Site (RTLS) - An RTLS would be performed for failures 
occurring between liftoff and the point at which the AMLS orbiter can no 
longer return to the launch site. An RTLS would be performed by 
jettisoning the PCS (if required), after which the AMLS orbiter would land at 
the SLF. During this time period, crew and passenger escape may also be 
performed by jettisoning the crew module and destroying the AMLS orbiter. 

• Trans- Atlantic Abort (TAA) - A TAA may be performed after the point in 
time when an RTLS is no longer possible. The PCS is jettisoned from the 
AMLS orbiter and the AMLS orbiter lands at an alternate landing site. 

• Abort-to-Orbit (ATO) - An ATO may be performed if it is determined that 
the AMLS orbiter can safely continue its mission. No jettisoning of the crew 
module would be performed. 

Probability of crew loss events (Table 3.3.3.17-2) were calculated for the AMLS 
based on engine-out capabilities as follows: (1) one booster engine and on ® 
orbiter engine can be lost during ignition and parallel bum, and (2) one orbiter 
engine can be lost after booster separation if all five were working at booster 
separation. 
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TABLE 3.3.3.17-2.- AMLS CREW LOSS EVENTS BY PHASE - 

PER 100 MISSIONS 


Phase 

Probability of Losses Per 
100 Missions 

Stage 1 and 2 Ignition 

0.1225 

Stage 1 and 2 Bum 

0.1129 

Staging 

0.0013 

Stage 2 Bum Phase 

0.0818 

Coast-to-Launch Apogee 

0.0009 

Orbit Circularization 

0.0001 

Total per 100 Flights 

0.319 


d. Architecture Cost Risk - The attribute values for ACR are Technical 
Challenge, Program Immaturity, and Number of New Systems. The AMLS 
Technical Challenge score is subdivided into Non-Recurring Production, 
Production, and Operations. The AMLS Technical Challenge subattribute 
values are Non-Recurring - 7 (ranges from 5 to 7), Production - 6 (ranges 
from 4 to 7), and Operations - 6 (ranges from 4 to 7). The AMLS final score 
for Program Immaturity was 8, with a range from 6 to 9. New systems 
received a score of 1.6, ranging between 1 and 2. 

e. Launch Schedule Confidence.- The three subordinate attribute values for 
schedule confidence - schedule compression, schedule margin, and delays 
due to unscheduled maintenance activities - are described below: 

(1) Schedule Compression . The maximum number of calendar days 
required for AMLS turnaround is 45.8 (including mission). 

Operations for processing through transport to the launch pad are 
performed on a 1-shift-per-day, 5-day-per-week schedule. The 
calendar days required for ground processing can be reduced to 19.7 
when all work is performed on a 3-shift-per-day, 7-day-per-week 
schedule. The operational scenario is shown in Figure 3.3.3.17-3. 

(2) Schedule Margin . Launch rates for the AMLS vary from a minimum 
of 4 per year in 2005 to a maximum of 13 per year in 2019. Depending 
upon individual facility usage, additional calendar days are available 
for contingency processing. A high of 249 additional processing days 
for a launch rate of 4 per year to a low of 14 processing days for a 
launch rate of 13 per year are available. 
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PCSs ARRIVE FROM 
PAYLOAD CUSTOMERS 




CARGO VEHICLES 
AND BOOSTERS ARRIVE FROM 
MANUFACTURER OR RETURNED FLIGHT 



HORIZONTAL PROCESSINC 
FACILITY (HPF) 



PAYLOAD CONTAINMEW 
SYSTEM PROCESSING 
FACILITY (PCSPF) 


TRANSPORTER 
MOVES LAUNCH 
VEHICLE TO PAD 


PCSs DEPART TO 
PAYLOAD CUSTOMERS 


Figure 3.3.3.17-3 - AMLS operational scenario at the launch site. 


(3) Delays Pup To Unscheduled Maintenance Actions . Based on a flight 
time of 168 hours and 35 hours of prelaunch checkout, the AMLS 
orbiter is expected to have a total of 169.5 unscheduled maintenance 
actions per mission, resulting in 33.9 line replaceable unit (LRU) 
removals. Approximately 23 percent of flights may be delayed by 
orbiter problems. The AMLS booster, with 35 hours of prelaunch 
checkout and a much shorter 15 minute flight, is expected to have 
only 15.9 unscheduled mainte-nance actions per mission and 4.2 LRU 
removals. Approximately 5 percent of flights may be delayed by 
booster problems. 

f. Environmental Impact.- The AMLS uses L0 2 and LH 2 as propellants. Toxic 
fluids have been eliminated. Using the given propellant weight, major effluent 
constituents were determined and are shown in Table 3.3.3.17-3. These values 
are based on equilibrium, non-afterburning calculations. 
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3.3.3.18 Advanced Military Spaceflight Capability (AMSC) 

System Description 

The AMSC is a one and one-half stage, air-launched system with a 5000 lb LEO 
payload capability. The system can be launched into any inclination. It uses three 
LOX/LH 2 engines in its main propulsion system. These are SSME-type engines 
which generate approximately one-third the thrust of an SSME. The AMSC concept 
was developed under a USAF study performed by Rockwell International. 9 The 
study effort used specific vehicle configurations to identify technologies required for 
an on-demand launch vehicle, and to provide a measure against which the needed 
technologies could be evaluated. The AMSC system was one of two prime 
candidates selected by the study team from a large number of possible 
configurations. 



Figure 3.3.3.18-1.- Rockwell’s AMSC concept used as a representative 
air-launched personnel carrier for HTS study. 


Performance Characteristics 

The AMSC concept was designed to deliver a 5000 lb payload to a 160 nmi polar 
orbit. Since this is the only performance value defined in the AMSC study, it was 
used for all AMSC missions. This does tend to overstate the number of missions 
required to support easterly launch requirements needed for most missions in our 
data base. It uses LOX/LH 2 propellants and expendable drop tanks. The carrier 
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aircraft is a slightly modified Boeing 747 on which the fuel tank orbiter is carried to a 
launch altitude of about 24 000 ft. This system provides favorable operational 
characteristics, such as being air-mobile and having inherent offset launch and base 
escape capabilities. A key system requirement characteristic was that the AMSC had 
to be maintained in an alert status, capable of being deployed within hours of 
notification. The use of existing transport aircraft for launch reduces system 
acquisition costs. A primary concern with this concept is the use of expendable 
tanks, which affect operational costs, and cause logistics, mating, and disposal 
problems. 

The drop tank orbiter is mated to the Boeing 747 in somewhat the same way as the 
Space Shuttle is mated to its carrier aircraft. Fully fueled, this configuration has a 
take-off weight of approximately 863 000 lbs, including the aircraft. Once airborne, 
liquid oxygen and hydrogen are transferred from the dewar tanks in the aircraft to 
the drop tanks; this continues until the aircraft is at approximately 24 000 ft. A 
pullup maneuver is executed to provide a flight path angle-of-attack of 
approximately 12° for AMSC separation. The separation-maneuver sequence 
represents the most technically demanding aspect of the entire vehicle operation. 
Once the AMSC vehicle and its attached drop tanks are separated from the aircraft, 
the three main engines are ignited and the vehicle ascends into space. At the time 
of separation, the GLOW is 2 77 000 lbs. After drop tank staging, 19 987 lbs of 
propellants remain in the AMSC vehicle to be burned by the three engines for final 
orbit insertion. The advanced RCS, which provides on-orbit and deorbit delta 
velocity, uses gasesous oxygen (GOX) /gaseous hydrogen (GH 2 ) fed from high 
pressure accumulators. A top-level, system mass statement is given in Table 
3.3.3.18-1. 

a. Abort Modes.- Two options for intact abort are available, depending on time 
from separation from the aircraft. If the center engine is lost prior to 

248 seconds, or an outboard engine is lost prior to 330 seconds, an abort to an 
appropriate runway is initiated. After these time constraints, either the two 
outer engines are throttled up, or the opposite outboard engine is shut down 
and the center engine is throttled up to achieve an ATO. 

b. Crew Escape Options.- A crew escape option was identified for the AMSC 
system. The discussed option focused on an ejection seat system although a 
detailed design was not included in the study. It is safe to assume that altitude 
and velocity limits as identified for the Shuttle Evolution (section 3.3.3.2) would 
approximate AMSC ejection operational limits. 

c. Operational Facilities.- The ground facilities for the AMSC system could be 
located at any air base capable of supporting a Boeing 747 that has equipment for 
mating the AMSC vehicle and its attached drop tanks to the aircraft. While the 
study did not define the ground facilities in detail, they were identified and 
discussed. Most of the building requirements are similar to typical commercial 
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TABLE 3.3.3.18-1.- AMSC MASS STATEMENT 


System breakdown 

Mass (klbs) 

747 Carrier aircraft 

581.6 

Drop Tanks 


Structure 

8.9 

Oxygen 

185.1 

Hydrogen 

30.8 

Orbiter 


Structure 

25.5 

Engines (3) 

4.7 

Oxygen - Ascent 

17.1 

Hydrogen - Ascent 

2.9 

Oxygen - RCS 

1.2 

Hydrogen - RCS 

0.2 

Payload 

5.0 

Total - GLOW 

863.0 


airport hangars, while specific support equipment for mating is considered to be 
small and portable, due to the small size and low empty-weight of the AMSC and its 
drop tanks. Fuel and payload facilities also have to be present. This system is 
designed to be mobile and launched from a variety of locations throughout the 
world. Since one of the AMSC's key characteristics is its ability to remain on alert 
status with lift off within hours of notification, its ground facilities had to be capable 
of continuously maintaining a full AMSC propellant load in the aircraft dewars. An 
operations flow schematic is shown in Figure 3.3.3.18-2. 

Attribute Values 


System input data related to each attribute, as well as system-specific attribute values 
are discussed below. In most cases, system data is modified by flight rate or cost 
associated with the particular architecture and/or "If" being evaluated. However, 
some useful observations can be made at the system attribute level. These will be 
discussed following the presentation of the AMSC system data. 

a. Human Safety.- Relevant system data for human safety consists of system 

characteristics that enable the crew to detach or escape from the main body of the 
system during ascent in the event of a mission failure. Two abort options 
(described earlier) exist and can be used in the event of a non-catastrophic main 
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engine failure. These are abort to nearest capable runway and ATO. If an ATO 
is executed, it is possible that the mission will be a success. In addition, the crew 
can eject from the vehicle with altitude and velocity constraints similar to those 
defined for Shuttle Evolution (section 3.3.3.2). 



OPF " Orbiter Processing Facility 

TPF ' Tank Processing Facility 

D • 8 Hr Day/1 Shift 


Turn Around 48 Hours (6-8 Hr Work Days Or 2-24 Hr Work Days) Possible 


Figure 3.3.3.18-2 - AMSC operations flow schematic. 


b. Funding Profile.- Cost information provided to the HTS included DDT&E; new 
airframe, engine, and drop tank production; and vehicle refurbishment. Spread 
factors for each cost item were also provided, identifying how much of the total 
cost was spent in the years preceeding the need or flight date. General Dynamics 
added annual preplanned product improvement, contractor fee, and 
government wraps as agreed to by the NIT. Table 3.3.3.18-2 presents a summary 
of this data. 
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TABLE 3.3.3.18-2.- AMSC FUNDING PROFILE INPUT DATA 


AMSC 

TOTAL 


RATE 

COST 

COST 

Y-5 

Y-4 

Y-3 


Y-l 

FLT 

COST BREAKDOWN 

ORTFU 

ING 

CURVE 

PER 

PER 






YR 

CATEGORIES 

COST 

CURVE 


FLT 

YEAR 








($M) 

(%) 

(%) 

($M) 

($M) 

(%) 

(%) 

(%) 

(%) 

(%) 

(%) 

NON-RECURRING 












RDT&E 

6478 





20 

25 

30 

e a 

m 


PRODUCTION 

0 











P3I 

324 /YR 











FACILITIES 












RECURRING 












NEW 












AIRFRAME 

669 

90 

100 



9 

16 

26 

El 

o 


MAIN ENGINE 

21 

90 

90 



8 

17 

27 

El 

m 


FLIGHT TO FLIGHT 












DROP TANKS 

14 

90 

90 



10 

15 

25 

m 



REFURBISHMENT 




1.4 

115.0 




_ 


100 

LAUNCH 

OPERATIONS 




0.5 

92.4 

■ 


■ 

■ 

■ 


FLIGHT OPERATIONS 




0.1 

25.9 






100 

R & M/SUPPORT 




0.0 

35.2 






100 


c. Probability of Mission Success - A system description and flight profile contains 
the required input information for this attribute. In summary, the AMSC has 
one liquid-propulsion stage, three liquid engines (with engine-out capability per 
the abort descriptions), and two solid motors used during the initial boost 
period. 

d. Architecture Cost Risk.- Two of three subordinate attribute values for ACR are 
Technical Challenge and Program Immaturity. The NIT, under a consensus 
process, assigned the AMSC a scale rating of 6 (Non-recurring), 4 (Production) 
and 6 (Operations) for Technical Challenge and a 7 for Program Immaturity, 
resulting in a value of 12.9, 4.6, and 12.9, respectively, in "If" C for Technical 
Challenge and a 21.5 for Program Immaturity (see section 3.2.5). The third 
component. Number of New Systems, is an architecture-level value. AMSC's 
contribution to architecture scores for this component of ACR is one. 

e. Launch Schedule Confidence - As in ACR, there are three subordinate attribute 
values for LSC: Schedule Compression, Schedule Margin, and Delays (due to 
unscheduled maintenance activities). Schedule Compression and Delays are 
architecture-independent, while Schedule Margin is architecture- dependent 
since its values are a function of annual flight rates, available facilities, and 
Orbiters. AMSC's Schedule Compression values are nominal cycle time - 41.2 
days, compressed cycle time - 24.8 days, and compression ratio - 0.6. It is 
estimated that the AMSC will experience delays in 9.9 percent of its flights. 
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f. Environmental Impact - The AMSC uses liquid hydrogen and liquid oxygen as 
propellants, as well as two solid strap-on boosters. Its propellant load includes 
oxygen - 1361.936 klbm, hydrogen - 227.641 klbm, and solid propellant - 2216.0 
klbm. Using the given propellant weights, major effluent constituents were 
determined and are shown in Table 3.3.3.18-3. These values are based on 
equilibrium, non-afterburning calculations. 


TABLE 3.3.3.18-3.- EFFLUENT DATA FOR AMSC* 


Exhaust 

AMSC 

Product 

(klbm) 

CO 

0.0 

CO 2 

0.0 

h 2 

8.0 

h 2 o 

223.2 

HC1 

0.0 

n 2 

0.0 

| OH 

0.0 1 

H 

0.0 

ai 2 o 3 

0.0 


* Does not include 747 engine effluents. 
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3.3.3.19 Air Launch Vehicle (ALV) 


System Description 

a. History - Air launching a rocket from a subsonic carrier aircraft has several 
advantages that should result in superior attribute scores. In the first part of the 
HTS, the NIT selected a candidate air launch concept to build an architecture 
around; refer to the AMSC description of section 3.3.3.18 of the HTS Final 
Report. This particular vehicle turned out to be sized incorrectly for the mission 
needs, and as a result, scored poorly in the AET. The NIT still believed that our 
customer considered the concept of air launching to be attractive, and that a 
more representative candidate should be included. The ALV is a configuration 
developed under independent research and development (IR&D) by Boeing 
Defense and Space Group and offered to this study as a concept better suited to 
the HTS mission needs. 

b. Configuration.- The ALV, see Figure 3.3.3.19-1, is a Boeing 747-launched, two 
stage LOX/LH 2 rocket that carries either a payload shroud or a small personnel 
capsule. The ALV 747 carrier airplane is a modified 400 series freighter with 
larger engines (PW4000’s from the 777 program) that is capable of lifting 
approximately 412 000 lbm to the launch conditions of 30 000 ft at a speed of 
770 ft/s. The ALV itself features an expendable wing, used for separation, a 
recoverable propulsion module with one SSME (operated at 100 percent rating), 
an expendable first stage tankset holding ~282 000 lbm of propellant, and an 
expendable second stage featuring one or two RL10A-4B engines and tankage for 
about 40 000 lbm of propellant. In the cargo version (CALV), a payload adapter 
and shroud are included. The second stage features one RL10 to reduce the 
recurring cost associated with expendable hardware. In the personnel version 
(PALV), the second stage features two RL10 engines, with engine-out capability, 
and an interface adapter to the human personnel carrier. The personnel capsule 
is very similar to the RPC biconic, except that it is smaller, carrying a maximum 
of four people for up to 3 days (72 hours) of travel time. 

c. Facilities.- The ALV is capable of taking off from any conventional Boeing 747- 
capable runway. Facilities for loading cyrogenic propellants are required in the 
immediate vicinity. The human personnel carrier facilities are nearly identical 
to those discussed in conjuction with the RPC. Figure 3.3.3.19-2 depicts a typical, 
ALV launch facility complex at the primary, flight operations site. 
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Performance Characteristics 


The PALV performance was sized to provide personnel-only-access for four 
passengers to the SSF. For the CALV, the payload performance is listed in 
Table 3.3.3.19-1. 

Attribute Values 

a. Funding Profile Summary - The ALV estimates were developed from a variety 
of cost-estimating techniques. The airplane modifications were estimated using 
proprietary Boeing airplane modifications and actual cost information analogies 
for each section of the 747 aircraft. The rest of the cost estimates for the funding- 
profile- attribute inputs were developed using the Boeing Parametric Cost 
Model. Table 3.3.3.19-2 is a summary of the system cost estimates. 


TABLE 3.3.3.19-1.- CALV PERFORMANCE SUMMARY 


Altitude 

(nmi) 

Inclination 

(deg) 

Payload (lbm) 

100 x 100 

90 

17,247 

GTO 

0 

8,104 

150 x 150 

28.5 

20,914 

30 x 220 

28.5 

22,425 

220 x 220 

28.5 

16,681 
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TABLE 3.3.3.19-2.- ALV COST ESTIMATES SUMMARY ("IF" C) 



(1992 Dollars in Millions) 

CALV PLS-Lite/PALV Total 

Development: 
C/D Phase 
Facilities 
Total: 

$ 3,277M 
385M 
$ 3,662M 


$ 4,925M 
642M 
$ 5,567M 

Production: 

Carrier A/C TFU 
Upper Stage TFU 
Expendable TFU 
Reusable TFU 
Supt. Equip. Set 

$ 244M 

41M 
36M 
162M 
$ 10.5M 

(same as CALV) 
53M (2 RLlO's) 
42M (OMS/LES) 
196M (mini carrier) 
(in DDT&E est.) 

Oper. & Support 
Variable Cost 
Fixed Annual 

m 

37M (first fit.) 
(same as CALV) 


• Acquisition Phase Estimates - The acquisition phase estimates were 
accomplished using new system weight statements and aircraft modification 
descriptions from a Boeing internal IR&D project activity. 

The cargo mission flight tests would precede the human mission tests, but 
the PLS-Lite drop tests and launch escape system tests can be done in parallel 
with the cargo mission hardware testing. The schedules were compared with 
Space Shuttle Carrier Aircraft, Airborne Optical Adjunct, and E-4 Command 
Post modification actual program schedules for content and reasonableness. 
The cryogenic stages development plan segment was compared with the 
Inertial Upper Stage program and NLS study program schedules for 
reasonableness and content. The SSME modification test schedule segment 
was compared with some prior study information from Rocketdyne and 
Phillips Labs. 

• TFU Estimates .- There are two configurations for the ALV cryogenic upper 
stage, so there are two TFU values shown in Table 3.3.3.19-2. The CALV 
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upper stage has one RL10 and the PALV upper stage has two RLlO's 
(induding extra plumbing and control subsystem impacts,) thus, the upper 
stage TFU cost estimates difference. Estimates are provided for expendable 
(exp) and reusable hardware elements. The PLS OMS/LES is expended on 
every flight. 

• Operation and Support Estimates - The variable cost estimate for the PALV 
configuration is higher to account for the PLS-Lite processing and 
refurbishment requirements. 

• Funding Profile Attribute Cost Inputs .- The ALV master phasing schedule 
includes the development plan for both CALV and PALV design and testing. 
The cost spread data was generated using the 6-year development plan 
illustrated in the preliminary ALV master phasing schedule. The funding 
profile, attribute cost estimate input sheet with the cost spread data is 
documented in Appendix B, section B.1.5. 

b. Probability of Mission Success - The mission success trees are listed in 
Appendix B. For the PALV, the PMS = 0.96649; for the CALV, PMS = 0.9473. 

c. Human Safety - The PALV includes a launch escape system that can provide for 
escape in all phases of the ascent. The Pd is equal to 0.00829, or an average of 
120.6 flights between crew loss events. 

d. Architecture Cost Risk - The ALV elements were evaluated with the same 
methods as other boosters. The Technical Challenge score was assigned a value 
of 4 (for all phases) based on the low level of required technology. The NIT 
accounted for the CALV and PALV as 1.5 "new systems", and agreed on a 
Program Immaturity value of 8. 

e. Operational Flow.- A summary operational flow for an ALV is shown in 
Figure 3.3.3.19-3. 

f. Environment - The ALV is a LOX/LH 2 system with a total W p of 321 482 lbm of 
propellant, resulting in a score of 32; refer to Table 3.3.3.19-2. 
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Figure 3.3.3.19-3 - Typical ALV launch operations preparation flow. 


TABLE 3.3.3.19-3.- EFFLUENT DATA FOR ALV 


Exhaust Product 

Effluent Mass 
(klbs) 

00 

0 

CO 2 

0 

h 2 

11.1 

h 2 o 

310.4 

HC1 

0 

n 2 

0 

OH 

0 

H 

0 

ai 2 o 3 

0 
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3.3.3.20 Two-Stage-to-Orbit (TSTO) Beta II 
System Description 

The Beta II TSTO (Figure 3.3.3.20-1) is a concept developed at the Air Force Wright 
Laboratory. NASA-Lewis selected it as its baseline TSTO concept in March 1990, 
bringing Boeing under contract in July as part of the NASA-Lewis /Wright Lab study 
team. Beta II is one of a family of TSTO’s under investigation within and outside of 
the United States. Other concepts include Sanger (Germany), HOTOL (UK/Russia) 
STAR-H (France), and LACE Boosted TSTO (Japan). Beta H has an air-breathing first 
stage, using turbofan and ramjet engines to accelerate up to Mach 6.5. Its orbiter has 
a single SSME to propel it from its Mach 6.5 staging point up to orbit insertion. The 
orbiter is loaded into the underside of the carrier aircraft. Performance design 
criteria is 10 klb of payload delivered into a polar orbit. The reference source for the 
Beta II is a NASA-Lewis briefing 10 , as well as the Boeing HTS team. 



Figure 3.3.3.20-1.- The Beta II concept is representative of fully reusable 
air-breathing/rocket TSTO systems. 


Performance Characteristics 

Beta II was designed to deliver a minimum of 10 klbs to polar orbit. Its performance 
to other orbits of interest is shown in Table 3.3.3.20-1. 


3.3-148 


Rev. E 



TABLE 3.3.3.20-1.- BETA H PERFORMANCE CHARACTERISTICS 
USED FOR MANIFESTING PURPOSES 


Inclination 

Apogee X Perigee 

Payload 

(deg) 

(nmi) 

(klbs) 

28.5 

160 x 160 

19.1 

28.5 

220 x 220 

18.5 

28.5 

300 x 300 

17.6 

57.0 

160 x 160 

15.6 

57.0 

324 x 324 

14.1 

90.0 

100 x 100 

11.1 

90.0 

150 x 150 

10.6 


The Beta n orbiter is mated into the bottom of its carrier aircraft. It sits inside a 
cavity during ascent or ferry operations. Its payload bay is 20 feet long with a 14-foot 
diameter. System GLOW is 1.2 Mlbs, of which 651.2 klbs is propellant, consisting of 
jet propellant (JP), liquid hydrogen, and liquid oxygen. A 20 percent and 10.6 percent 
weight-growth allowance has been accounted for in the carrier aircraft and orbiter, 
respectively. Total inert weight is 234.6 klbs. A top-level mass statement is shown 
in Table 3.3.3.20-2. 


TABLE 3.3.3.20-2.- BETA H MASS ALLOCATION 


Mass Allocation 

Carrier Aircraft 
(lbs) 

Orbiter 

(lbs) 

Inert 

181,677 

52,948 

Propulsion 

218,215 


Propellant 

377,651 

273,499 

Crew and Residuals 

9,815 

2,901 

Payload 

345,160 

10,000 

Margin 

79,976 

5,595 

Total 

1,212,494 

344,943 
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There is a 217 lb discrepancy between the orbiter total mass and the carrier aircraft 
payload. This may be due to propellant boil off between take off and staging, round- 
off error, or other analytical discrepancies. However, this small difference could 
easily be allocated to margin, propellant, or residuals in order to force numbers to 
coincide. 

Mission operations begin with take off from a Strategic Air Command-type runway 
using air-breathing propulsion. A total of 10 NASA-Lewis Research Center turbine 
bypass engines, using JP-fueled high speed civil transport technology, provide initial 
thrust up through Mach 3. Beginning at Mach 1.5, hydrogen fueled ramjets are 
brought on line at partial-thrust levels. They provide 100 percent of the thrust 
between Mach 3 and Mach 6.5, where the orbiter is released. After staging, the 
carrier returns to its base of operations under powered flight, using ramjets only, 
down to a speed of Mach 3, and turbofans only from Mach 1.5 to landing. The 
orbiter’s SSME is ignited after release from the carrier aircraft to continue 
acceleration through orbit insertion. Orbit circularization is provided by two RL10- 
A4 engines, which draw propellant from the main propulsion tanks. An integral 
GOX/ GH 2 RCS provides attitude and reaction control. At the end of its mission, the 
Beta II orbiter deorbits and glides to its landing site just as the Space Shuttle Orbiter 
does today. 

a. Abort Modes.- Beta 13 abort modes are defined in Figure 3.3.3.20-2. 


Orbiter Trans- Atlantic 
Abort La nding 
Options: 

1. Morocco 

2. Gambia 

3. Spain (2 sites) 


Orbiter Down-Range 
Abort Landing 

Options: 

1. S. Africa 

2. Liberia 

3. Zaire 

4. Australia 



KSCTackoff to Vehicle 
Separation Options: 

1. CobacktoKSC 
2 Land at Loring AFB, Maine 

3. Land at Argenda NAS, New Brunswick 

4. Land at Halifax RCAFB, Nova Scotia 

5. Land at Keflavik NAS, Iceland 



Orbiter On-Orbit 
Abort Options 
Abort Once Around: 

1. White Sands, N.M. 

2 EAFB, Calif. 

Abort-to-Orbit: 

1. Rescue from KSC 
2 Rescue from VAFB 
3. International Rescue 

Abort From Orbit: 

Forty (40) designated 
NST5 emergency landing 
sites (Shuttle plans.) 


Figure 3.3.3.20-2 - Beta II abort and contingency operations. 
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b. Crew Escape Options - B-58-type ejection capsules enable crew escape from both 
the carrier aircraft and the orbiter. 

c. Operational Facilities.— An overview of basing facilities is given in 

Table 3.3.3.20-3. This study assumed that only one site was developed since all 
azimuths are available from any launch site for a two stage, fully reusable 
launch system. Figure 3.3.3.20-3 shows the Beta II operational flow schematic. 


TABLE 3.3.3.20-3.- BETA II FACILITIES OVERVIEW 


Facility 

Kennedy Space Center 

Vandenburg Air Force Base 

Runway 

300 ft wide x 15 000 ft long. 

200 ft wide x 15 000 ft long. 

Taxiways 

Limited to none. 

Limited. 

Orbiter Processing 
Facility 

Existing are 100 percent utilized by 
Space Shuttle. 

Existing former Space Shuttle 
orbiter Maintenance and Checkout 
Facility is not being utilized. 

Booster Processing 
Facility 

No hangar facilities - limited 
facilities at Patrick Air Force Base. 

No suitable hangar facility. 

Support facilities - Shops, 
Administrative, and 
Logistics 

Existing Space Shuttle, Titan, Atlas 
and Delta launch support facilities 
at KSC and CCAFS plus aircraft 
maintenance facilities at Patrick 
AFB. 

Existing Titan, Atlas and ballistic 
missile launch support facilities. 
Extremely limited aircraft 
maintenance facilities. 

Propellant Storage and 
Distribution 

Cryogenic propellant storage at 
Launch Complex 39 pads; 

Suitable distribution nonexistent; 

Aircraft propellant storage and 
distribution facilities are limited to 
nonexistent. 

Cryogenic propellant storage at 
SLC-6 launch pad; 

Suitable distribution nonexistent; 

Aircraft propellant storage and 
distribution facilities are limited to 
nonexistent. 

Payload Processing 
Facility 

Existing facilities to support Space 
Shuttle, Titan, and Delta payloads 

Existing facilities in former Space 
Shuttle Orbiter Maintenance and 
Checkout Facility. 

Mission Control Facility 

Titan, Atlas and Delta facilities 
with communication links; 

Established Test Range. 

Titan and Atlas "on-pad" facilities 
with communications links; 

Established Test Range. 

Automated Test and 
Checkout 

Existing Launch Control Center with 
Launch Processing System - probably 
completely dedicated to Space 
Shuttle; 

Proposed "CORE" update to LPS 
may be suitable and have required 
capability. 

Space Shuttle equipment and 
facility status unknown; 

Ballistic missile programs' current 
and future status unknown; 

Highly doubtful that suitable assets 
exist. 
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Attribute Values 


System input data related to each attribute, as well as system-specific attribute values 
are discussed below. In most cases, system data is modified by flight rate or cost 
associated with the particular architecture and/or "If" being evaluated. However, 
some useful observations can be made at the system attribute level. These will be 
discussed following the presentation of the Beta II system data. 

a. Human Safety - Relevant system data for human safety consists of system 

characteristics that enable the crew to detach or escape from the main body of the 
system during ascent in the event of a mission failure. Several abort options 
(described earlier) exist and can be used in the event of a non-catas trophic main 
engine failure. They are abort to nearest capable runway and ATO. If an ATO is 
executed, it is possible that the mission will be a success. In addition, the crew 
can eject from either vehicle as described above. 




I 

MAJOR OVERHAUL . 

EVERY 30 FLTS 1 

183 days 1^” 

5d-lsft . 


I 

I 


Figure 3.3.3.20-3.- Beta II operations flow schematic. 


3.3-152 


Rev. E 









b. Funding Profile - Cost information provided to the HTS included DDT&E, 
production, vehicle refurbishment, and operations. Spread factors for each cost 
item were also provided, identifying how much of the total cost was spent in the 
years preceding the need or flight date. General Dynamics added annual pre- 
planned product improvement, while the AET added contractor fee and 
government wraps, as agreed to by the NIT. Table 3.3.3.20-4 presents a summary 
of this data. 

c. Probability of Mission Success.- A system description and flight profile contains 
the required input information for this attribute. In summary, the Beta n has 3 
liquid-propulsion stages consisting of 10 turbojet engines and 2 ramjets in the 
first stage, 1 main rocket engine in the second stage, and an orbital maneuvering 
system as the third propulsive stage. The PMS process does not use the air- 
breathing stage to determine mission success rate. This is also true for the 
AMSC concept. 


TABLE 3.3.3.20-4.- BETA II FUNDING PROFILE INPUT DATA 


Beta II 

Cost Breakdown 
Categories 

Total 
Or TFU 
Cost 
($M) 

Learn- 

ing 

Curve 

(%) 

Rate 

Curve 

(%) 

Cost 
Per Fit 
($M) 

Cost 

Per 

Yr 

($M) 



Yr 

-6 

(%) 



i 

1 

Yr 

-1 

(%) 

nt 

Yr 

(%) 

Non-Recurring 






■ 

m 


■ 

■ 

■ 

■ 



RDT&E 

15538 





m 

EE 

EE 

E 

EE 

E 


m 


Production 

703 







IEE 

m 

m 

m 

■ 

m 


P3i 

777/Yr 





■ 

■ 


m 

BE 





Facilities 







r 

r 

r 






Eafb Test Facility 

348 





m 

BtS 

EE 

EE 






Ksc Facilities 

375 





m 

EE 

H^tj 

es 

S3 





Vafb Facilities 

452 





■ 

m 


IE 


m 




Moc/Training 

200 





m 



IE 

m 

■ 




Fit Training A/ C 

100 





m 

EE 

EE 

El 

m 





Recurring 



■■ 



m 

■ 

■1 


m 

■ 




New 















Carrier Aircraft 

2940 

95 

100 








EE 


EE 

5 

Orbiter 

703 

92 

100 








EE 

EE 


5 

19% Rplcmnt Spares 

692 

92 

100 








■ 

■ 

■ 

100 

Carrier #1 Mod 

735 

100 

100 











10 

Orbiter #1 Mod 

176 

100 

100 










FT 

20 

Launch Operations 




wm\ 

310 









100 

Flight Operations 




7 

120 









100 

R & M/Support 





46 









100 
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d. Architecture Cost Risk.- Two of three subordinate attribute values for ACR are 
Technical Challenge and Program Immaturity. The NTT, under a consensus 
process, assigned the Beta II a scale rating of 8 (Non-recurring), 7 (Production) 
and 8 (Operations) for Technical Challenge in "If" C, and a 10 for Program 
Immaturity, resulting in a value of 35.9 (Non-recur), 21.5 (Production), and 35.9 
(Operations) for Technical Challenge and a 100 for Program Immaturity (see 
section 3.2.5). The third component. Number of New Systems, is an 
architecture-level value. Beta H's contribution to architecture scores for this 
component of ACR is 1. 

e. Launch Schedule Confidence.- As in ACR, there are three subordinate attribute 
values for LSC: Schedule Compression, Schedule Margin, and Delays (due to 
unscheduled maintenance activities). Schedule Compression and Delays are 
architecture-independent, while Schedule Margin is architecture-dependent 
since its values are a function of annual flight rates and available facilities and 
Orbiters. Beta H's Schedule Compression values for the orbiter are: nominal 
cycle time - 14 days, compressed cycle time - 14 days, and compression ratio - 
1.0. It is estimated that 8.9 to 14.8 percent of Beta n flights may experience a 
flight delay. The estimate is based on assessing the orbiter and carrier aircraft 
separately, with an orbiter estimate of 8.9 percent and 5.9 percent for the carrier 
aircraft. 

f. Environmental Impact.- The Beta II uses jet fuel, liquid hydrogen, and liquid 
oxygen as propellants. Propellant load on the carrier aircraft is 3 77 651 lbs, of 
which 250 010 lbs is jet fuel and 127 641 lbs is liquid hydrogen. Approximately 
half (122 270 lbs) of the jet fuel is used during parallel operation of the turbofans 
and ramjets. The remainder is allocated to take off and acceleration to Mach 1.5, 
return propulsion, and contingency needs. The orbiter's 273 499 lbs of propell- 
ant is 39.1 klbs of hydrogen and 234.4 klbs of oxygen. Using the given propellant 
weights, major effluent constituents were determined and are shown in Table 
3.3.3.20-6. These values are based on equilibrium, non-afterburning calculations. 

TABLE 3.3.3.20-5.- EFFLUENT DATA FOR BETA H 


Exhaust 

Product 

Beta II 
(klbm) 

CO 

0.0 

C02 

377.5 

h 2 

11.0 

h 2 o 

481.9 

HC1 

0.0 

N2 

0.0 

OH 

0.0 

H 

0.0 i 

Al 2 03 

0.0 
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3.3.4 Architecture Evaluation Process 


Having defined the transportation architectures to be analyzed, described the systems 
which comprise the architectures, and developed methodologies for measuring the 
important attributes, it is now possible to evaluate the architectures using the tools the 
HTS study developed. Figure 3.3.4-1 illustrates the architecture evaluation process and 
the flow of data between the data analysis tools. The figure indicates the major 
computer models and the data inputs and outputs of each. 

The first step in the architecture analysis process is to gather or develop the basic 
system data required to either determine architecture flight rates or attribute values, 
such as ascent performance and reliability trees. Then the manifesting and mission 
capture work is done. For the HTS study, this was accomplished using General 
Dynamics' Transportation Systems Integration Tool (TRANSIT). TRANSIT applies 
system performance data, various system constraints, and other data to the mission 
model to produce a series of manifests. One manifest, which summarizes the total flight 
requirements by year over the study time frame, is produced for each "IP activity 
scenario of an architecture. 

Once the mission capture analysis is complete and the architecture manifests are 
produced, the next step is analysis of the ground operations flow. To do this, a top-level 
flow diagram is developed for each launch system. These diagrams show the major 
facilities required for a system and the length of vehicle processing time and shift 
information for each. They also show which processes are done in parallel and which 
are done in series. From these diagrams, the operations spreadsheet models are 
developed. The models produce the system level, operations-related, attribute data 
required for attribute calculation. This includes schedule confidence and schedule 
margin data for the Launch Schedule Confidence attribute. The models also produce 
data for the number of facilities and vehicles required for the architecture cost 
estimation. 

Information from the ground operations analysis, manifests, and system cost data 
inputs are used to produce the cost data for each architecture. This is accomplished in a 
spreadsheet model which was developed in previous studies and modified to produce 
cost data in the format required by the study. Data produced for each system, in each 
architecture, includes year-by-year costs for DDT&E, facilities, non-recurring 
production, preplanned product improvement, operations, and recurring production. 

The cost model also uses PMS and safety values to estimate the cost of vehicle losses 
due to unreliability. The PMS values come from spreadsheet analysis based on 
reliability success trees. Safety values come from spreadsheets, which tally the potential 
losses and their effect on crew survival and abort for each flight phase. 

Finally, data for the six study attributes, as well as the flight rate manifests, are input 
into the HTS AET. The AET is a Macintosh-based evaluation model, developed 
specifically for the HTS study, which utilizes system and element level data to generate 
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Figure 3.3.4-1- HTS process data flow. 
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architecture-level attribute data and utility scores. It contains all algorithms necessary 
to "roll up" the data, both across all systems in the architecture and over the study time 
frame, into architecture values. The values are applied against utility curves to produce 
attribute scores. These scores are then combined using attribute weightings to produce 
architecture scores. Both attribute and architecture scores can be used to compare 
architectures and help address various considerations. The AET is the final evaluation 
tool for the extensive amount of data generated from the various HTS models, tools, 
and processes. 
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3.3.5 HTS Reference - Architecture Option 1 


The HTS Reference (Architecture 1) provides a benchmark for HTS study processes 
and a comparative reference for potential replacement architectures. Systems in the 
HTS Reference comprise the first 8 years of all architectures. NASA's Mixed Fleet 
Manifest defines the system flights from 1992 through 1998. New systems or 
capabilities are not introduced until after 2000. 


3.3.5. 1 Description 

Current systems and operational characteristics, defined as those in place or under 
development, comprise the HTS Reference Architecture. These include: Shuttle 
with ASRM's; Atlas (E, I, and HAS); Delta II; and Titan (II, m, and IV) (see 
figure 3.3.5. 1-1). Facilities and operational flow paths are discussed in the relevant 
system section. Small commercial vehicles (Pegasus, Taurus, Conestoga, etc.) or 
sounding rockets (Scout, Aires, etc.) are not considered in this study. 



Figure 3.3.5.1-1- Reference architecture launch system vehicles (not to scale). 


Space Shuttle improvements incorporated in the baseline include the ASRM's and 
EDO. The ASRM's increase payload lift capability by 12 klbs relative to the 
redesigned solid rocket motors (RSRM’s) now being used. The EDO increases on- 
orbit duration capability from 10 days to 30 days. However, since all personnel 
mission flights were assumed to be 7 days in length, the extended duration capability 
is not considered. Also, it does not affect fleet size requirements, even though it 
provides longer mission times. 
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Atlas E and I flights are treated as HAS vehicles from an operational viewpoint since 
there are only 2 and 4 flights of each, respectively, out of 94 total flights. Also, since 
there are only two Atlas flights from WTR, the operational analysis has been 
simplified by assuming that all flights are out of ETR. 

The single Titan in flight in the Mixed Fleet Manifest has been treated as a Titan IV 
in the operational analysis. These simplifications are common to all architectures 
since the flights occur between 1992 and 1998. They have no bearing on relative 
comparisons between architectures. 


3.3.5.2 Manifesting Philosophy 

Missions between 1992 and 1997 are defined by the NASA Mixed Fleet Manifest in 
effect in August 1991. For all scenarios ("If's") one DOD Space Shuttle mission was 
included per year. Beyond 1997, all payloads going to the SSF, all human-tended 
payloads, and all return payloads were manifested on the Space Shuttle. For other 
destinations, as a priority, untended payloads were manifested onto expendable 
launch vehicles without crews. The Assured Crew Return Vehicle (ACRV) was 
delivered to and returned from SSF using the Space Shuttle. This philosophy 
reflects the way payloads are currently or are planned to be handled using the 
current systems. Two payloads identified in the CNDB and carried forward into the 
HTS mission model ("If" D) were modified so the Space Shuttle could deliver them 
to SSF; assembly payloads MB-19 (70 klb) and MB-24 (69.5 ldbs) were split into two 
equal-mass payloads, with no additional ASE added. 


3.3.5.3 Manifesting Results 

The ELV flights remain constant across all "If" scenarios, with Space Shuttle 
increasing from 76 to 389 flights over the 29 years of interest in this study (Table 
3.3.5.3-1). Annual rates for Space Shuttle begin at 3 in "If" A, increase to 4 in "If" B, 
jump to 10 through 12 in "If" C, 11 through 15 in "If" D, 11 through 15 in "If" E-low, 
and 11 through 17 in "If" E-high. 

Annual Space Shuttle flight rates and their Orbiter fleet size for "If's" C and D are 
shown in Figure 3.3.5.3-1. Space Shuttle flight rate peaks at 12 in 1997 (late FY91 
Mixed Fleet Manifest), in 2000, and in 2007. Need for a fifth Orbiter is indicated at a 
rate of 11 flights per year (approximately 2.5 flights per year, per Orbiter). This is 
somewhat lower than KSC's estimate of achieving 12 flights per year with a four- 
Orbiter fleet. A key difference in these rates may be the assumption that each Orbiter 
is off-line 60 days per year to account for a 180-day major modification every 3 years. 
"If" D generally requires one to two flights more than "If" C each year to support the 
EMCC SSF, except in 2002, where the rate peaks at 15 per year during EMCC build up. 
Thus, a six-Oribter fleet is required for "If" D, beginning in 2000. 
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The highest traffic model ("If" E-High) Space Shuttle flight rate and Orbiter fleet size 
is shown in Figure 3.3.5.3-2. Flight rates peak at 17 per year (2011) in this If . A 
seven-Orbiter fleet is required in 2007 to meet the demand of 16 flights that year. 
Sixteen Space Shuttle flights are also required in 2015, 2018 and 2020. 


TABLE 3.3.5.3-1.- REFERENCE ARCHITECTURE SYSTEM FLIGHT SUMMARY 


SYSTEM 

EAST 

WEST 


TOTAL 

NASA 

DOD 

NASA 

DOD 

Atlas I 

4 





4 

Allas E 



1 

1 


2 

Allas DAS 

24 

64 




88 

Della 

38 

111 

10 

33 


192 

Tilan II 



3 

39 


42 

Titan HI 

1 





i 

Tilan IV/Centaur 

42 

56 




98 

Titan IV/NUS 


61 

24 

57 


142 

Shuttle -"If 1 A 

47 

29 




76 

-”ITB 

119 

29 




148 

-"If" C 

271 

29 




300 

-"If' D 

309 

29 




338 

."If’ E-LOW 

328 

29 




357 

-“IT E-HIGH 

360 

29 



_ 

389 


LATE FY 1991 MIXED FLEET MANIFEST 



IFCFLT/YR 

IF C FLEET SIZE 

--- 1FDFLT/YR 

IF D FLEET SIZE 


Figure 3.3.5.3-1.- SSF support requirements raise Space Shuttle flight rates 
up to 16 per year and Orbiter fleet size to 6 per year. 
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Figure 3.3.5.3-2.- "If" E-High drives Space Shuttle flight rate to a 
peak of 17 in 2011 and fleet size to 7 in 2007. 


Other than a new west coast pad for Titan and a new MLP, the only procurement 
required for this architecture to satisfy the HTS-defined needs are new Orbiters. The 
required fleet size increases from four to seven as the mission model expands from 
"If' C to "If" E-High. With the predicted loss rate for the Orbiter (see section 
3.3.5.4.1), the replacement requirements are greater than the fleet build-up 
requirements. 


3.3.5.4 Architecture Evaluation 

The Reference Architecture provides a benchmark for the defined methodologies 
and potential replacement architecture assessments. Therefore, discussion of 
attribute values, the Space Shuttle's contribution to those values, and increased 
asset requirements to meet various scenarios is presented. 

Increased assets that enable the Reference Architecture to meet ETO requirements 
include a Titan IV launch pad. Space Shuttle Orbiters, and an MLP. The operations 
models indicate that all scenarios require an additional Titan IV pad on the west 
coast in 1999 to support defined DOD flights. Additional Space Shuttle Orbiters and 
MLP's to support scenarios which include SSF ("If" C through E-high). Annual 
flight rates in "If's" A and B do not require additional Orbiters or MLP's. The 
Orbiter fleet must increase from four to five in 1996 ("If's" C through E-high), from 
five to six ("If" D through E-high) in 2000, and from six to seven ("If" E-high) in 
2007. One additional MLP is required in 2003 for "If's" D through E-high. 
Additional Orbiters are also required to compensate for probable vehicle loss due to 
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catastrophic failures (two in "If" A, three in "If" B, six in "If' C, seven in "Ifs" D and 
E-low, and eight in "If" E-high). 

3.3.5.4.1 Attribute summary 

a. Human Safety - Figure 3.3.5.4.1-1 shows the projected number of crew loss 

events (to the nearest tenth) by "If" for this architecture. The probability of crew 
loss (0.02235) is solely attributable to the Space Shuttle, as it is the only personnel 
system in this architecture. This value projects a crew loss event every 44 to 45 
flights. Actual experience resulted in a crew loss event on the 25th Space 
Shuttle flight. Through the end of calendar year 1992 there has been 1 crew loss 
in 52 launches, for a demonstrated value of 0.019231. 



Figure 3.3.5.4.1-1- Projected crew losses through 2020. 


b. Funding Profile - Projected total architecture cost values and peak year funding 
requirements are shown in Figure 3.3.5.4.1-2. Since expendable vehicle flight 
rates in this architecture are constant across all "If's", increased cost values are 
directly related to the increase in Space Shuttle flights as space program activity 
increases from "If" A to "If" E-High. The Space Shuttle's contribution to the 
Total Architecture Costs by "If" is shown in Table 3.3.5.4.1-1. 

c. Probability of Mission Success - Table 3.3.5.4.1-1 shows the architecture PMS 
value for each "If", which ranges from a low of 0.9317 ("If" A) to a high of 0.9354 
("If' E-High) and is directly attributable to the increased number of Space Shuttle 
flights for each successive "If". System PMS values, flight rates, and system 


3.3-162 


Rev. E 



contributions to the Architecture PMS for each "If" are shown also. The 
Architecture PMS value varies by less than one hundredth of a point across the 
time period of the study. Thus, any replacement system with a significantly 
different PMS should be readily discernible when viewing the annual PMS 
values. 


TABLE 3.3.5.4.1-1.- SYSTEM CONTRIBUTIONS TO 
ARCHITECTURE PMS VALUES 



IF A 

IFB 

IF C 



Fits 

Pms*Flts 


Pms*Flts 


Pms*FIts 

SYSTEMS 

Pms 

Total Fits 

Fits 

Total Fits 

Fits 

Total Fits 

Atlas E 

0.9326 

2 

0.002891 

2 

0.002601 

2 

0.002146 

Atlas I 

0.9326 

4 

0.005783 

4 

0.005202 

4 

0.004292 

Atlas IIAS 

0.9326 

88 

0.127238 

88 

0.114461 

88 

0.094440 

Delta II 

0.9319 

192 

0.277402 

192 

0.249546 

192 

0.205897 

Titan II 

0.9626 

42 

0.062680 

42 

0.056386 

42 

0.046523 

Titan III 


i 

0.001442 

i 

0.001298 

1 

0.001071 

Titan IV/NUS 


142 

0.204898 

142 

0.184322 

142 

0.152082 

Titan IV/Centaur 


98 

0.138263 

98 

0.124379 

98 

0.102623 

Space Shuttle 

0.9431 

76 

0.111124 

148 

0.249546 

300 

0.325581 

Architecture Total 


645 

0.9317 

717 

0.9329 

869 

0.9347 



IFD 

IF E-LOW 

IF E-HIGH 




Pms*FIts 


Pms*Flts 


Pms*Flts 

SYSTEMS 

Pms 

Fits 

Total Fits 

Fits 

Total Fits 

Fits 

Total Fits 

Atlas E 


2 

0.002056 

2 

0.002014 

2 

0.001946 

Atlas I 

1 

4 

0.004112 

4 

0.004028 

4 

0.003893 

Atlas IIAS 

0.9326 

88 

0.090483 

88 

0.088627 

88 

0.085666 

Delta II 

0.9319 

192 

0.197271 

192 

0.193223 

192 

0.186769 

Titan II 


42 

0.044574 

42 

0.043660 

42 

0.042201 

Titan in 


i 

0.001026 

i 

0.001005 

i 

0.000971 

Titan IV/NUS 

0.9307 

142 

0.145710 

142 

0.142720 

142 

0.137953 

Titan IV/Centaur 

0.9100 

98 

0.098324 

98 

0.096306 

98 

0.093089 

Space Shuttle 

0.9431 

338 

0.351452 

357 

0.363592 

389 

0.382949 

Architecture Total 


907 

0.9350 

926 

0.9352 

958 

0.9354 
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PEAK FUNDING 
REQUIRED 
($92 M) 



A B C D E-LOW E-HIGH 

HTS SPACE PROGRAM ACTIVITY LEVEL (IFS) 


Figure 3.3.5.4.1-2.- Total architecture cost and peak year funding requirement. 


d. Architecture Cost Risk - Total values for the Technical Challenge sub-attribute 
of ACR are shown in Figure 3.3.5.4.1-3. The values associated with "If's" A and 
B represent the minimum values achievable, since each system in this 
architecture for those "If's" is currently in operation and, therefore, has zero 
risk. The change in the risk level for "If's" C and above is attributable to the 
ACRV program. Program Immaturity for the Reference Architecture has a 
value of one, reflecting the fact that all launch systems are operational 
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throughout the architecture time frame. There is, however, one new system in 
this architecture for "If's" C through E-high, namely, the ACRV. Thus, the New 
System subattribute value for those "If's" has a value of one. These values were 
developed by consensus using the scale defined in section 3.2.5. 



TECHNICAL CHALLENGE 



A B C D E-LOW E-HIGH 

HTS SPACE PROGRAM ACTIVITY LEVEL (IFS) 


Figure 3.3.5.4.1-3.- Reference architecture subattribute technical challenge value. 


e. Launch Schedule Confidence - Operational considerations for the HTS 
architecture comparison are contained in this attribute, which consists of three 
sub-attributes: Schedule Compression, Schedule Margin, and Launch Delays. 
Schedule Compression reflects the amount of time that system processing can be 
shortened through maximizing personnel utilization; by extending shift 
durations up to 50 percent and working shifts which are not part of the nominal 
processing plan. The Reference Architecture can achieve slightly less than a 50 
percent reduction in processing clock time (Figure 3.3.5.4.1-4). Schedule Margin 
indicates how many additional launches can be made using existing assets at 
nominal processing schedules. The evaluation of the Reference Architecture 
indicates that an additional four to six flights per year across all systems could be 
flown using assets required to meet the peak requirements from 1992 through 
2020. The analysis indicates that launch delays due to unscheduled 
maintenance actions would occur on 7 to 12 percent of the scheduled flights 
between 1992 and 2020. 

f. Environment - Figure 3.3.5.4.1-5 shows the relative environmental impact the 
Reference Architecture has, based on nozzle effluents. These data only have 
relevance as a reference for other architectures within this study. They should 
not be used as absolute indicators of damage to the environment. Using "If' C 
(SSF remains at PMC) as a comparative reference: "If" A has about half the 
impact, "If" B has 67 percent of the impact, "If" D is 8 percent greater, "If" E-Low 
is 12 percent greater, and "If" E-High is 19 percent greater. The biggest 


3.3-165 


Rev. E 





contributor in all but "If" A is the Space Shuttle, with its contribution to the 
total growing from 48 percent in "If" B to 71 percent in "If' E-high. Titan 
contributes the largest percentage of the value in "If" A, accounting for 
56 percent of the total. 



Figure 3.3.5.4.1-4.- LSC subattribute values for schedule compression, schedule 
margin, and launch delays due to unscheduled maintenance 
actions. 
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Figure 3.3.5.4.1-5- Environmental impact attribute values. 


3.3.5.4.2 Final scoring. - Figure 3.3.5.4.2-1 shows a stacked bar chart, delineating each 
attribute in its unweighted and weighted proportions. Comparing the unweighted 
to weighted scores for this architecture shows that the weighting factors increase the 
importance of Funding Profile and Human Safety while decreasing the importance 
of ACR, LSC, and Environment. It appears as though the attribute weights had 
minimal impact on the relative contribution of PMS. 

3.3.5.4.3 Analysis of score.- Reference Architecture and attribute scores provide a 
basis for comparison with other architectures defined to address specific considera- 
tions. As such, it is not possible to say if they are good or bad. The Reference 
Architecture received a total score of 40 to 55 out of 100 for the various scenarios 
considered. Architectures with higher scores than the Reference within a specific 
"If" are deemed to be better than the Reference and may be viable alternatives for 
the future. However, these scores are highly dependent upon the chosen utility 
curves and relative weights of each attribute. Therefore, one must examine specific 
attribute values and total score sensitivity to attribute weightings before discarding 
or promoting specific architectures. It is possible to conclude that the nation finds 
the attribute values associated with the Reference Architecture as acceptable 
consequences, since the operation is continued. 
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3.3.6 Shuttle Evolution - Architecture Option 2 


A viable way to increase capacity, improve capabilities, or provide more options at 
low cost is by modifying existing systems. Examples abound in military and 
commercial aircraft (e.g., B-52, B-l, Boeing 727 and 747, Airbus 300, etc.). The Shuttle 
Evolution architecture employs this principal to enhance the capabilities of the 
Space Shuttle, Atlas, Delta and Titan launch systems. Since all systems, except Delta, 
incorporate evolutionary characteristics, the architecture title Shuttle Evolution is 
something of a misnomer. This architecture was devised to show how well current 
systems could handle future space activity requirements if they were improved 
along a pre-defined path. Evolutionary aspects were not optimized based on initial 
architecture evaluations or single attribute measurements. 


3.3.6. 1 Description 

As in the Reference Architecture, Shuttle Evolution consists of current operational 
systems (see Figure 3.3.5. 1-1). However, specific performance and operational 
characteristic enhancements are incorporated, beginning in 2000. Outward 
appearance changes for Evolution include the replacement of solid motors with 
liquid boosters on the Space Shuttle and an increase in the Titan IV core diameter 
from 10 to 14 feet. Specific improvements in each system are described below and in 
Table 3.3.6.1-1. 


Space Shuttle improvements include ET and Orbiter modifications, replacement of 
solid rocket motors (SRM’s) with LRB's, crew ejection capability, and operational 
flow reductions. Additionally, an unpiloted RCV has been added to the Space 
Shuttle fleet. This element is a new vehicle with the Orbiter's outer mold line, a 
unique pressurized volume for the avionics, and redistributed subsystems for 
center-of-gravity improvements. Its enhanced characteristics allow it to deliver up 
to 80 klbs to SSF. The impetus for developing the RCV is that it allows untended 
cargo to be delivered to orbit without using a piloted vehicle, and yet makes full use 
of the in-place Space Shuttle infrastructure and its fixed-cost base. After evaluation, 
a second Shuttle Evolution was defined which used hybrid rocket boosters (HRB's) 
instead of LRB's and incorporated a crew escape module (CEM) in the piloted 
orbiters. The CEM Orbiters were introduced by replacing the entire existing fleet 
with the new design. Old orbiters were converted to unpiloted orbiters rather than 
building new RCV's. 

Atlas improvements include reductions in processing flow times and modifications 
to the Centaur upper stage. These changes reduce prelaunch pad time from 42 to 23 
days. Thirty-seven work days with one shift each are reduced to 20 days, also with 
one shift. The remaining 5 days are reduced to 3 days by going to 24-hour work days 
at the equivalent of 1.75 shifts per day. On the Centaur, two RL-10 engines have 
been replaced with a single, higher thrust, RL-10 derivative. 
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TABLE 3.3.6.1-1.- SYSTEM IMPROVEMENTS IN EVOLUTION ARCHITECTURE 


SYSTEM ENHANCEMENTS 


BRIEF EVOLUTION CONCEIT DESCRIPTION 


Light Weight External Tank 
LRB's 


SSME Limited to 
100% 

Single-Launch 

I-Loads 

After Major Modification 
LDO 

Advanced Thermal Protection 
System 

New Vehicles Only 
Light Weight 
Orbiter 

Electromechanical 
Actuators 
Ejection Seats (8) 


3000 Lbs Weight Reduction 

LOX/RP; 4 Engines per Booster; Engine Out 
Each Booster 

Increased Engine Reliability and 
Operational Life 

Reduction in Nominal Payload and 
Mission Operations Costs 

90-Day On-Orbit Capability to Support 
Man-Tended SSF Operations 

Reduced Maintenance Items Between 
Flights 

5000 Reduction in Orbiter Weight Due To 
Material Changes 

Elimination Of Hydraulic Actuation 
System 

Four Seats in Upper and Lower Right 
Deck 


Reusable Cargo 
Vehicle 


Orbiter Mold Line with Special 
Pressurized Compartment for Avionics 
and Redistributed Subsystems for CG 
Improvement 


Atlas 

Reduced Processing 
Time 

Single-Engine 

Centaur 


Removes Centaur from Critical Row 
Path 

Improves Overall Centaur Stage 
Reliability; RL-10 Thrust Increased 


Titan IV 

14-Ft Diameter Core 


Provides Increased Lift Capability - 
Maintains SRMU’S 


The Titan IV evolution concept consists of a 14-ft diameter core, versus the current 
10-ft diameter. It retains the two SRMU strap-ons to provide lift-off thrust. This 
concept also includes modifications to the facilities and a reduction in operational 
flow times. Performance is increased from 37.7 (28.5 x 160 nrni circular) for Titan IV 
to 62.1 for Titan Evolution. 
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3.3.6.2 Manifesting Philosophy 

Payloads were manifested following the same basic principles employed in the 
Reference Architecture: Space Shuttle and Shuttle Evolution captured all human- 
tended missions, SSF payloads, and return requirements. Untended payloads were 
preferentially manifested on ELV's. The major difference between this architecture 
and the Reference is the existence of the RCV as part of the Shuttle Evolution 
system, which was used for all SSF payloads except crew rotation and SSF "Facility" 
payloads. Since RCV's role was limited to SSF support, it does not appear in the 
architecture for "If's" A or B. 


3.3.6.3 Manifesting Results 

The ELV flights remain constant for all activity levels ("If s"), with Space 
Shuttle/Shuttle Evolution increasing from 76 to 396 (Table 3.3.6.3-1). RCV accounts 
for 83 Space Shuttle flights in "If' C and 97 in "If s" D through E-High. Annual 
flight rates for Space Shuttle/Shuttle Evolution stay below five per year in "Ifs" A 
and B. For "Ifs" C through E-high, the peak Space Shuttle/Shuttle Evolution flight 
rate increases from 13 to 17. 

Relative to the Reference Architecture, total ELV flights are unchanged except that 
two-thirds to three-fourths of them are now on evolved systems. The Space 
Shuttle, however, has considerable changes in its total flights, except in "If" A, 
which has the same total as the Reference with two-thirds being on Shuttle 
Evolution. Counting Space Shuttle, Shuttle Evolution and RCV flights, there are 
eight fewer flights in "If" B, 27 more in "If" C, and seven more in "If" D through "If" 
E-High. On the other hand, the number of human-tended flights is reduced by 0, 8, 
56, and 90 for "Ifs" A, B, C and D through E-High, respectively. The decrease in 
flights within "If" B relative to the Reference results from increased lift capability of 
Shuttle Evolution. However, for "Ifs" C through E-High, the increase in Space 
Shuttle System flights relative to the Reference Architecture is driven by the 
manifesting process. The RCV was manifested first, ensuring that its payload bay 
was full every time it flew. Orbiter flights were forced to fly four crew exchange 
missions per year, splitting no more than a full RCV cargo bay over four Space 
Shuttle flights. This utilized about 20 percent of the Orbiter's capacity, on average. 
Reversing this strategy, i.e., filling the four Orbiters to capacity on crew exchange 
flights and using the RCV only for what remains, could reduce total flights to SSF by 
one or two per year. 

The alternate Shuttle Evolution Architecture had an increase of nine Space Shuttle 
system flights (327 to 338) due to the lower performance of the CEM Orbiter and 
Unpiloted Orbiter relative to the Orbiter and RCV for "If' C. Unpiloted flights 
remained unchanged at 83; Orbiter flights increased from 97 to 99; and 147 Evolution 
Orbiter flights increased to 156 CEM Orbiter flights. 
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TABLE 3.3.6.3-1- EVOLUTION ARCHITECTURE SYSTEM FLIGHT SUMMARY 



EAST 

WEST 

TOTAL 

SUPER 

TOTAL 

SYSTEM 

NASA 

DOD 

NASA 

DOD 

Atlas I 

4 




4 

4 

Atlas E 



1 

1 

2 

2 

Atlas IIAS 

5 

25 



30 

88 

Atlas Evolution 

19 

39 



58 

Delta II 

8 

33 

6 

6 

53 


Delta Evolution 

30 

78 

4 

27 

139 

192 

Titan II 



3 

39 

42 

42 

Titan in 

1 




1 

1 

Titan IV/Centaur 

7 

17 



24 

98 

Titan Evolution/Centaur 

35 

39 



74 

Titan IV/NUS 


20 

4 

18 

42 

142 

Titan Evolution/NUS 


41 

20 

39 

100 

Space Shuttle - "IT A 

18 

8 



26 

76 

Shuttle Evolution 

29 

21 



50 

RCV 





63 


Space Shuttle - "IT 1 B 

55 

8 




Shuttle Evolution 

56 

21 



77 

140 

RCV 





97 


Space Shuttle - "IT C 

89 

8 




Shuttle Evolution 

126 

21 



147 


RCV 

83 




83 

328 

Space Shuttle - "If” D 

93 

8 



101 


Shuttle Evolution 

126 

21 



147 


RCV 

97 




97 

345 

Space Shuttle - "IT E-Low 

93 

8 



101 


Shuttle Evolution 

145 

21 



166 


RCV 

97 




97 

364 

Space Shuttle - "If 1 E-High 

93 

8 



101 


Shuttle Evolution 

177 

21 



198 


RCV 

97 




97 

396 


Facility and reusable element requirements have been estimated based on the 
required flight rates generated by the manifesting process, vehicle processing times, 
and facility dwell times. Table 3.3.6.3-2 lists the quantities for each system element 
comprising Architecture 2. Each system's flight and facility elements are listed in 
the left hand column. 

The column labeled "exist" indicates the number of each facility in 1992. Entries in 
the "Growth" columns indicate the additional number of elements needed to meet 
the required flight rate. "Replacement" entries tell the reader how many reusable 
flight elements are required to offset probable losses due to catastrophic failure. 
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TABLE 33.6.3-2.- FACILITY AND REUSABLE ELEMENT REQUIREMENTS 


ARCHITECTURE ELEMENT 


Shuttle 


EXIST 


A--1 B C D 


CRflWTH 


E-Ll E-H 


Al B. 


REPL A CEMENT 


XL 


X=L 


XXL 


Orbiter 

Evolved Orbiter 
Reusable Cargo Vehicle 
Mobile Launch Platforms 
Launch Pads 

Orbiter Processing Facility 
Vertical Integration Cells 


4 


3 

3 

2 

2 


1 

2 


1 

2 


1 

2 


1 1 
4 4 
2 3 


1 

4 

3 


1 

5 

3 


Atlas 

Booster Processing Facility 
Centaur Processing Facility 
Hazardous Processing Facility 
Launch Pads - East 


3 

1 

1 

2 


Delta 

Booster Processing Facility 
Launch Pads - East 
Launch Pads - West 


3 

2 

1 


Titan III/IV 


Vertical Integration Building Cells 
Solid Motor Assembly Building Cells 
Titan Transporter 
Launch Pads - East 
Launch Pads - West 


4 

5 
4 
2 
1 


1 


Titan II/IIS 


i 


Vertical Integration Building Cells 0 

Shared with Titan III/IV 

Solid Motor Assembly Building Cells 0 

Shared with Titan III/IV 


Titan IIS Transporter 
Launch Pads - East 
Launch Pads - West 


0 

0 

1 


33.6.4 Architecture Evaluation 

Overall, the Evolution Architecture scores better than the Reference, except in "If's" 
A and B. This is primarily due to the reduction in crew loss events caused by the 
introduction of the RCV. In addition. Environmental values for the Evolution 
Architecture are significantly reduced since the Space Shuttle SRB's were replaced by 
hydrogen and oxygen LRB's. 
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The Reference Architecture scored better in "If s" A and B because without SSF 
there is no need for the RCV, hence, no reduction in crew loss events. There is a 
reduction in the Environmental Impact values but not enough to overcome the 
increase in Funding Profile. In fact, the Reference fairs better across all "If s" in 
Funding Profile, ACR, and LSC. Environmental Impact (the lowest weighted 
attribute) is the only attribute where the Evolution Architecture consistently 
outscores the Reference. 

PMS is higher for the Reference in "If s" C through E-High because Shuttle 
Evolution's PMS decreased due to the addition of LRB's. On the other hand, in 
"If s" A and B, the Evolution Architecture faired better because Centaur modifica- 
tions for Atlas and Titan IV increased their PMS. This, along with Atlas and Titan 
having a greater percentage of total flights at these activity levels, raised the 
Architecture PMS with respect to the Reference. 

The Evolution Architecture scores can be improved in two ways: remanifest SSF 
payloads so that the Orbiter's payload bay is full during crew exchange missions and 
redefine Shuttle Evolution to provide greater crew abort capability or higher PMS. 

3.3.6.4.1 Attribute summary 

a. Human Safety - Figure 3.3.6.4.1-1 shows the projected number of crew loss 
events (to the nearest tenth) by "If for this architecture and the Reference 
Architecture. The probability of crew loss is 0.02235 for the Space Shuttle and 
increases to 0.02278 for Shuttle Evolution. These values equate to a crew loss 
event every 44 to 45 (44.7) flights for Space Shuttle and 43 to 44 (43.9) for Shuttle 
Evolution. Changes in Shuttle Evolution definition to used HRB's instead of 
LRB's, and the incorporation of the CEM, decreased crew loss events by 0.7 (4.8 
to 4.1) on over 150 flights compared to a 1.9 reduction (6.7 to 4.8) realized by 
adding the RCV to the fleet. 



Figure 3.3.6.4.1-1- Projected crew losses through 2020. 
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Even with this higher rate, projected crew loss events are lower for the 
Evolution Architecture due to the addition of the untended RCV, which is used 
to support SSF. The increase in probability of crew loss events is driven by the 
PMS, discussed in the next paragraph, and mitigated by Shuttle Evolution 
characteristics with regard to crew survivability. Specifically, these include the 
ability to shutdown LRB’s during the boost phase and the addition of ejection 
seats in the Orbiter, and the addition of RCV to the Space Shuttle vehicle fleet. 
The ability to shut down the LRB's and the addition of ejection seats just offset 
the increase in mission failures attributed to the LRB's, as can be seen by the 
similar crew loss events for "If’s" A and B. The reduction in piloted missions 
resulting from the addition of RCV is primarily responsible for the reduction in 
crew loss events in "If's” C through E-high. 

b. Funding Profile - Projected total architecture cost values and peak year funding 
requirements are shown in Figure 3.3.6.4.1-2. Since expendable vehicle flight 
rates in this architecture are constant across all "If's", increased cost values are 
directly related to ELV and Shuttle Evolution costs and the increase in Space 
Shuttle system flights as space program activity increases from "If" A to "If 
E-High. The increase in Total Architecture Cost incurred to implement the 
alternate evolution concept is approximately $16B in 1992 dollars. This increase 
is about equally split between DDT&E and fleet replacement. 

c. Probability of Mission Success - Figure 3.3.6.4.1-3 shows the architecture PMS for 
each "If" relative to the Reference Architecture. The absolute value is 
somewhat higher than the Reference Architecture for "If’s" A through C and is 
lower for "If's" D through E-High. Actual PMS values for this architecture 
range from 0.9347 ("If" E-High) to 0.9360 ("If" B). This is a function of the 
relative number of reference and evolution flights for each system, especially 
within the Space Shuttle system (including RCV). The decrease in PMS from 
"If" B to "If" E-High is driven by Shuttle Evolution's lower value relative to 
Space Shuttle and the constant ELV flight rates across "If’s". System PMS 
values, flight rates, and contributory portions for each "If' are shown in Table 
3.3.6.4.1-1. For the alternate Shuttle Evolution definition, PMS recovers about 
half the decrease it experienced between Space Shuttle and Shuttle Evoluation. 

d. Architecture Cost Risk - Values for ACR, and each of its subattributes (technical 
challenge, program immaturity, and number of new systems) are shown in 
Figure 3.3.6.4.1-4. These values were developed by consensus, using 
mathematical processes and scales defined in section 3.2.5. Overall risk 
associated with this architecture is low, as there are no new technology or major 
operational philosophy changes. The attribute value comes for modifying three 
of four systems and operating an automated reusable element. This architecture 
ranks second-highest in all "If's", except A and B. This is expected as all new 
elements are based on current operational systems. There is an insignificant 
difference in ACR between the two architectures featuring different Shuttle 
Evolution approaches. 


3.3-175 


Rev. E 




Figure 3.3.6.4.1-2- Total architecture cost and peak year funding requirements. 



Figure 3.3.6.4.1-3- PMS values. 
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TABLE 3.3.6.4.1-1.- SYSTEM CONTRIBUTIONS TO ARCHITECTURE PMS VALUE 


SYSTEMS 


IF A 


IFB 


IF C 


Pms 


Fils 


Pms*Flts 
Total Fits 


Fits 


Pms*Flts 
Total Fits 


Fits 


Pms*Flts 
Total Fits 


Atlas E 
Atlas I 
Atlas HAS 
Atlas Evolution 
Delta II 

Delata Evolution 
Titan II 
Titan in 
Titan IV/NUS 
Titan Evolution 
Titan IV/Centaur 
Titan IV/Cent EVO 
Shuttle 

Shuttle Evolution 
RCV 


0.9326 

0.9326 

0.9326 

0.9326 

0.9319 

0.9319 

0.9626 

0.9307 

0.9307 

0.9519 

0.9100 

0.9166 

0.9431 

0.9290 

0.9290 


2 

4 

30 

58 

53 

139 

42 

1 

42 

100 

24 

74 

26 

50 


0.002892 

0.005784 

0.043377 

0.083862 

0.076575 

0.200828 

0.062681 

0.001443 

0.060604 

0.147581 

0.033860 

0.105160 

0.038016 

0.072016 


2 

4 

30 

58 

53 

139 

42 

1 

42 

100 

24 

74 

63 

77 


0.002631 

0.005261 

0.039461 

0.076292 

0.069662 

0.182700 

0.057023 

0.001313 

0.055133 

0.134260 

0.030804 

0.094979 
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Figure 3.3.6.4.1-4.- ACR subattribute values for technical challenge, program 
immaturity and number of new systems. 
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e. Launch Schedule Confidence - Values for the attribute as a whole, and each 
subattribute are shown in Figure 3.3.6.4.1-5. Evolution's increase in LSC values 
is attributable to the increase in processing flow margins of the evolved systems 
(Atlas, Titan, and Space Shuttle). The increase in margins is primarily the result 
of increased system-lift capacity (fewer flights) and reduced processing times. 
There is some slight, but insignificant, change in schedule compression due to 
processing time and shift changes. Also, the projected number of unscheduled 
maintenance actions resulting in launch delays are virtually identical at this 
level of system definition. There is very little difference in LSC values 
associated with the two definitions for Shuttle Evolution. 
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Figure 3.3.6.4.1-5.- Launch schedule confidence subattribute values for schedule 
compression, schedule margin, and launch delays. 
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f. Environment - The Evolution Architecture has about one-third the impact of 
the Reference Architecture, independent of mission activity level (Figure 
3.3.6.4.1-6). A key to this reduction is replacement of the Space Shuttle SRB's 
with LRB's, although the advantage gained is offset in part due to the increased 
size of the Titan IV core stage. This reduction is significant and indicates that 
nozzle effluents should be a consideration for future launch system concepts. 
The two Shuttle Evolution definitions evaluated exhibited a minimal difference 
in Environmental Impact. 


ENVIRONMENTAL 

IMPACT 


4.0E+06 

3.5E+06 
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1.0E+06 

5.0E+05 

0.0E+00 



HTS SPACE PROGRAM ACTIVITY LEVEL (IFS) 


Figure 3.3.6.4.1-6.- Environmental impact attribute values. 


3.3.6.4.2 Final Scoring - Ordinal ranking of all architectures by "If" places the 
Evolution Architecture between fifth ("Ifs" C through E-Low) and ninth ("If" A). In 
"If s" B and E-High, this architecture is ranked sixth. Figure 3.3.6.4.2-1 shows the 
total weighted architecture score for each "If". To show how unweighted attribute 
scores compare to the weighted score, a stacked bar chart has been provided, 
delineating each attribute in its natural and weighted proportions (Figure 3.3.6.4.2-2). 

Relative to the Reference Architecture, the Evolution Architecture clearly scores 
better within "If's" C through E-High, and is equivalent to the Reference for "Ifs" A 
and B. The reduction in crew loss events (about two out of seven) resulting from 
the introduction of the RCV is the biggest contributor to score improvement. Other 
attributes with improved values include LSC and Environmental Impact. For "Ifs" 
A and B, the improvement in crew loss events, PMS / LSC, and Environmental 
Impact were offset by the increases in Funding Profile and ACR. 
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Figure 3.3.6.4.2-1.- Total architecture score and ranking 
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Figure 3. 3. 6. 4. 2-2.- Attribute score and weighting contributions to final score. 
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Figure 33.6.4.2-2 shows the impact that the relative attribute ranking has on the 
make-up of the architecture score. 

Overall, the evaluation of the two distinct Shuttle Evolution concepts with regard to 
booster type and crew escape enhancements provided insignificant improvements 
in overall architecture scores. 

33.6.4.3 Analysis of score - Upon reviewing the architecture scores and their key 
contributors. Evolution comes out ahead of the Reference in two attributes: Human 
Safety, the highest weighted, and Environmental Impact, the lowest weighted. 
Funding Profile and ACR exhibit similar differences, with the Reference scoring 
higher. Launch schedule confidence scores are equivalent across all "If s", while 
PMS exhibits a reversal from "If A to E-High. In "IFs" A and B, PMS is significantly 
better for the Evolution Architecture, whereas, in "Ifs" C through E-High, 

Evolution and Reference scores are equivalent, with the Reference lower in "If C 
and higher in "If E-High. 

Crew loss events are down because fewer human-tended missions are flown in the 
Evolution Architecture relative to the Reference. Almost all of the reduction in 
crew loss events can be attributed to introduction of the RCV. If PMS for Shuttle 
Evolution could be improved, it would add a great deal to the value of the 
Evolution Architecture, since the gains in crew safety due to LRB's and ejection 
seats are offset by the decrease in predicted PMS value for the system. This can be 
seen by comparing crew loss events in "Ifs" A and B. This requires further 
examination of the definition of Shuttle Evolution. 

Environmental Impact scores are vastly improved because the solid motors on the 
Space Shuttle are replaced with LOX rocket propellant boosters. Titan Evolution 
reduces the potential improvement somewhat, due to its increase in core diameter 
and propellant load for improved performance. This increases Titan's 
Environmental Impact value by slightly more than 20 percent. 

The analysis of two different Shuttle Evolutions indicated that crew losses were 
reduced (0.7 events or 41 percent) but at a substantial ($25 B or 12 percent) increase in 
cost. The customer needs to decide whether this should be spent to eliminate one 
projected crew loss event. 

33.6.4.4 Conclusions and recommendations - Although Shuttle Evolution was 
defined in a way that was believed to improve its PMS and Human Safety attributes, 
it turned out that its PMS was diminished. Fortunately, its Human Safety 
characteristics were enhanced so that it is about equal to that of the existing Space 
Shuttle. The underlying reason for the reduction in PMS is replacement of the 
SRB's with LRB's. The process for determining PMS uses historically-demonstrated 
reliability values for large solid motors, liquid engines, and liquid propulsion stages. 
Solid motors have the highest value, liquid engines have the next highest, and 
liquid stages have the lowest. By replacing the Space Shuttle solid motors with 
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LRB's, the system's PMS is significantly reduced during the initial ascent phases. 
Enhanced crew safety was realized because of the ability to shutdown and eject the 
LRB's during this same period, as well as the addition of ejection seats. As a result, 
the cost of Shuttle Evolution did not produce a net decrease in crew loss events 
since the enhanced crew safety features only offset the increased rate of mission 
failures. 

It is recommended that the definition of Shuttle Evolution be revisited to ensure a 
net decrease in crew loss events. This may include retaining the SRB's, 
incorporating a frangible crew module in die Orbiter design, using hybrid boosters 
instead of liquid boosters, or using single-engine LRB's. The second Shuttle 
Evolution definition incorporated a crew escape module with full-ascent capability, 
and substituted HRB's for the LRB's. These changes provided very little in overall 
architecture evaluation but indicated that the cost is considerably more to reduce 
crew loss events by this means, than through the introduction of an unpiloted 
orbiter. 

Finally, the manifesting philosophy should be revisited with regard to RCV and 
Shuttle Evolution for SSF payloads. It will be possible to reduce total Space Shuttle 
system flights by one or two RCV's per year simply by filling the Shuttle Orbiter 
cargo bay to capacity for crew exchange missions, thereby reducing mission failures 
and unreliability costs through the reduction of total flights. 
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3.3.7 


Alternate Access - Architectures 1. 3, and 4 Compared 


3.3.7.1 Description 

As referenced in section 3.2.12, the desirability of Alternate Access was addressed 
through a set of comparative architectures, in addition to the attribute that was 
dropped at the mid-point of this study. The set of Architectures 1, 3, and 4 have 
been structured to provide this comparison. While there is a clear advantage to 
having an Alternate Access to space, it is difficult to quantify these benefits. With 
the programmatic decision not to conduct a Monte Carlo (or similar) mission loss 
simulation due to the cost and complexity involved, it was realized early-on that a 
direct comparison between the existing baseline (Architecture 1) and the "baseline 
plus (never used) Alternate Access" would address only the question of: "How 
expensive is Alternate Access?" A Monte Carlo simulation could have developed 
"probable costs" associated with Space Shuttle downtime and resulting forced 
evacuations of SSF due to lack of Alternate Access. Such costs could then have been 
used to offset the development costs of new systems. Past experience has indicated 
NASA’s reluctance to invest money in low-probability-of-usage backup capabilities, 
with a preference to rely instead on making the primary system function as it 
should. 

Consequently, the comparison architectures were prepared from the standpoint of 
simultaneously off-loading the Space Shuttle to reduce overall costs. First, in 
Architecture 3, up-cargo was off-loaded from the Space Shuttle as much as possible, 
using ELV’s. In Architecture 4, people are also off-loaded from the Space Shuttle, by 
means of an RPC, and a cargo return vehicle (CRV) is provided to facilitate meeting 
down-cargo requirements. The specific selection of the Boeing biconic RPC with 
minimum cargo capacity, implicitly introduces a "separation of people and cargo" 
philosophy, which is treated in detail in Section 3.3.8. In both cases, the Space 
Shuttle must remain fully operational in order to provide the reserve, alternate 
access means, expensive as a result of high fixed costs with low flight rates, for those 
off-loaded capabilities, either people or cargo. 

The ACRV remains the emergency return vehicle for the SSF crew in all cases. It 
would be rotated to and from SSF by the Space Shuttle under normal circumstances, 
for periodic maintenance. 


3.3.7.2 Manifesting Philosophy 

The three architectures have only the following common elements: 

• The Space Shuttle remains operational through 2020. 

• The ACRV is the SSF crew emergency return vehicle. 
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In Architecture 1: 


• The Space Shuttle is improved through P 3 I, and remains the primary vehicle 
for all human-related missions. 

• All payloads to and from SSF go on the Space Shuttle. 

• The Delta-Atlas-Titan family of ELV's preferentially carry payloads not 
requiring human presence. 

• No new families of ELV's or personnel /cargo carriers are developed. 

In Architecture 3: 

• The Space Shuttle continues to carry all personnel and all return-cargo. 

• The Space Shuttle handles only those delivery-cargo needs that cannot be 
carried on ELV's. 

• The NLS-family of ELV’s is introduced, replacing Atlas and Titan ELV's one 
(5-year) period after the introduction of NLS-3 and -2, respectively. 

• A CTV is introduced to transfer cargo from an NLS-element through 
rendezvous with a specific orbital target (e.g., SSF). 

In Architecture 4: 

• An RPC (Boeing biconic concept - minimum cargo capability) is introduced 
for carrying personnel, and the Space Shuttle is used for personnel 
transportation only when the RPC is inadequate or unavailable. 

• A CRV is introduced that preferentially handles return cargo. 

• NLS and CTV introductions are the same as in Architecture 3. 

• The only preferential use for the Space Shuttle is non-SSF, "human-at- 
receipt" missions (e.g., servicing of the Hubble Space Telescope). 


3.3.7.3 Manifesting Results 

Table 3.3.7.3-1, below, summarizes the flight activity for these three architectures for 
"IPs” C, D, E-Low, and E-High. Owing to the lack of SSF in "IF's" A and B, in terms 
of which Alternate Access is defined, there is no relevant difference between the 
architectures therein; the only differences are those caused by the phase-out of Atlas 
and Titan in favor of the NLS-family. 
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TABLE 3.3.7.3-1.- ALTERNATE ACCESS IN SUPPORT OF SSF 



(Numbers of Flights of Indicated System) | 


Shuttle 


Total CTV: 
(NLS-HL& 
NLS-50) 
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190 
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Arch 3 
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83 


163 

246 

953 

Arch 4 

44 

85 

83 
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361 

1068 




i H— W 





|IFELo minus B 







I Arch 1 l 

209 




209 

209 

926 


182 


83 


182 

265 

972 

| Arch 4 

44 

104 

83 

153 

148 

380 

1087 









|!FE Hi minus B 







Arch 1 

241 




241 

241 

958 

Arch3 

214 


83 


214 

297 

1004 

Arch 4 

44 

136 

83 

153 

180 

412 

1119 


In Table 3.3.7.3-1, the "non-SSF' flight activity represented by "If’ B has been 
subtracted out for each architecture, leaving only the effects of SSF operations and, 
in "If E, the additional burden of SEI crew transportation. Such subtraction also has 
the effect of removing the ELV system configurations which have constant flight 
rates in support of unmanned operations. The reader is referred to in Appendix B, 
section B.1.2 for the total flight numbers relative to these architectures. 

By way of example. Table 3.3.7.3-1 shows that the "If C configuration of SSF can be 
supported by an additional 152 Space Shuttle flights in the Reference Architecture 1; 
by an additional 139 Space Shuttle flights and 79 CTV flights in Architecture 3; or 
with 28 additional Space Shuttle flights, 84 RPC flights, and 79 CTV flights in 
Architecture 4. The RPC's and CTV’s are carried on NLS boosters in these 
architectures, but could just as easily be carried on appropriately rated Titan or MLS 
vehicles. Also, it may be noted that the entire burden of supporting SEI crew 
transportation remains on the Space Shuttle in Architecture 3, but is entirely 
supported by the RP C in Architecture 4. 
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3.3.7.4 Architecture Evaluation 


3.3.7.4.1 Attribute summary - Table 3.3.7.4-1 contains a summary of attribute values 
for Architectures 1, 3, and 4, including the presence of SSF. 


TABLE 3.3.7.4-1- ALTERNATE ACCESS ARCHITECTURE ATTRIBUTE 

SUMMARY 
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3.3.7.4.2 Final scoring - Based on the "Overall Architecture Scores," Architectures 1, 
3, and 4 are clustered closely together, roughly in the middle, scorewise, of all of the 
architectures evaluated in this study. The maximum spread (7.3 percent of 
Architecture 1 over 4 in "If" C) is only a weak discriminator. It is worth noting 
however, that Architecture 1 (the baseline) ranks higher in overall score than either 
Architecture 3 or 4 in all cases. A cursory examination shows that this is due to the 
significantly higher Architecture 1 scores for Funding Profile (no DDT&E since 
system already exists) and ACR (lowest risk since it already exists) overriding the 
lower scores in the Human Safety and PMS Attributes. Except in "If" E-High, where 
it appears to have become overburdened. Architecture 3 always ranks higher than 
Architecture 4. 

Based on the analyses in the following sections and the intangible benefits derived 
from Alternate Access, it would appear that implementation of neither Architecture 
3 nor Architecture 4 would be warranted. Based on the manifesting philosophies, 
guidelines, and attributes utilized herein, the baseline (Architecture 1), with 
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replacement of vehicle losses and a better crew escape system, is clearly superior to 

either of them. 

3.3.7A.3 Analysis of scores and considerations 

a. Human Safety - The improvements in Human Safety arise from two sources, as 
indicated in the right-hand side of Table 3.3.7.4-2. In Architecture 3, the 
relatively modest improvement is due to the reduction in the number of Space 
Shuttle flights. This was achieved by eliminating the need to carry cargo via the 
Space Shuttle to SSF when there is no associated crew rotation requirement. In 
Architecture 4, the additional improvements come from the off-loading of crew 
rotations for SSF and SEI to the RPC, vehicle with its integral crew escape system 
and more reliable NLS-2 booster. 

Putting this in perspective, one may calculate a "Cost per Life Saved" by 
assuming a typical crew size of six, multiplying that by the number of crew loss 
events avoided by employing Architecture 3 or 4, and dividing the result into 
the associated incremental cost. The results range from $7.3 B per life saved 
down to $2.8 B in "If" E-High, both associated with Architecture 3. These 
calculations are crude, and may be offensive to some. The intent, however, is to 
show the extraordinarily poor return on the dollar in the Human Safety area. 
Clearly, economical increases in human safety are insufficient justification for 
implementation of Architectures 3 or 4. It would be more cost effective to 
retrofit the Space Shuttle with a crew escape system that is effective from the 
pre-launch, "on-pad" period throughout the launch phase. 

b. Funding Profile - To assess the costs attributable to the provision of Alternate 
Access, it is appropriate to again subtract "If" B from the other "If’s." The results 
are shown in Table 3.3.7.4-2. This has the effect of removing NLS-family 
DDT&E costs from consideration, as these are incurred in "If’s" A and B 
regardless of whether alternate access is implemented or not. It should also be 
noted that the RPC, CRV, and cargo transfer vehicle (CTV) are not used at all in 
"If’s" A and B since there is no SSF to support, so their DDT&E costs appear for 
the first time in "IF" C. From such subtraction and comparison, it is readily 
apparent that the incremental cost of supporting the basic SSF with "cargo-only" 
Alternate Access is 1.63 times that of using the Space Shuttle exclusively. 
Similarly, the cost of providing Alternate Access for both personnel and cargo, 
as implemented in Architecture 4, is 4.85 times that of using the Space Shuttle 
alone. 

In the same vein, the incremental peak year funding requirements for the above 
two cases are 1.41 and 7.25 times greater than with the Space Shuttle, although 
the peaks do not necessarily occur in the same year from architecture to 
architecture. 
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The relevant incremental costs and ratios for the other "If's" are readily 
discernible in Table 3.3.7.4-2. The cost increment ratios for each architecture 
decrease with increasing flight utilization (i.e., going from "If" C to "If" E-High) 
as the lower recurring cost per flight slowly amortizes the investment in 
infrastructure and DDT&E that went into creating the new elements. In other 
words, it takes a large number of missions for the lower cost per mission "non- 
Space Shuttle" systems to show any significant payback of their required 
investments. Unfortunately, the flight rates required, even in the "If's" E, are 
insufficient to recapture those investments within the time horizon of this 
study, much less yield savings. 


TABLE 3.3. 7.4-2 - ALTERNATE ACCESS COST AND SAFETY 
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Given the intangible nature of benefits from Alternate Access, it is not possible 
to compute a Benefit-to-Cost ratio directly. However, the additional costs 
involved in supporting SSF in this mode in the customarily constrained NASA 
budgetary environment would appear to be an unacceptably high burden. 
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c. Probability of Mission Success - In an attempt to quantify the costs of achieving 
a greater number of flights with mission success through the implementation of 
Alternate Access, Table 3.3.7 .4-3 was developed. Unfortunately, Architectures 3 
and 4 are not only significantly more expensive and somewhat more reliable 
than the reference architecture, but due to the fact that a higher total number of 
flights is required to fulfill the SSF and SEI needs, have more lost missions. Put 
another way, more money is being spent to lose more missions (but not human 
lives - see Safety, above) which is not an inducement for implementation of 
either Architecture 3 or 4. 


TABLE 3.3.7.4-3.- ALTERNATE ACCESS PMS SUMMARY 




Increment $ 




Increment in 





Absolute 

Total # 

Missions 

Missions Not 

Mission 


Total $ 

over "IF’ B 

PMS 


Not Accomp 

Acc over B 

Saved 

IF B (Ref) 








Arch 1 

156,459 


0.9361 

717 

45.8 



Arch 3 

174,000 


0.9478 

707 

36.9 



Arch 4 

174,000 


0.9478 

707 

36.9 
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IFC 








Arch 1 

177,404 

20,945 

0.9374 

869 

54.4 

8.6 


Arch 3 

208,111 

34,111 

0.9468 

925 

49.2 

12.3 

-3,538 

Arch 4 

275,616 

101,616 

0.9454 
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56.3 

19.4 

-7,467 
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Arch 1 

183,876 

27,417 

0.9376 

907 

56.6 

10.8 


Arch 3 
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953 

50.8 

13.9 

-3,524 

Arch 4 
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Arch 1 

185,281 

28,822 

0.9377 

926 

57.7 

11.9 


Arch 3 

215,514 

41,514 

0.9466 

972 

51.9 

15.0 

-4,060 

Arch 4 

285,260 

111,260 

0.9453 

1087 

59.5 

22.6 

-7,719 









IFEHi 








Arch 1 

192,109 

35,650 

0.9379 

958 

59.5 

13.7 


Arch 3 

219,794 

45,794 

0.9465 

1004 

53.7 

16.8 

-3,238 

Arch 4 



0.9455 

1119 

61.0 

24.1 



d. Architecture Cost Risk - The Space Shuttle system was considered to be 

programmatically risk-free since it is fully operational. Architecture 3 includes 
the NLS development risk as well as that associated with the CTV. Its generally 
high scores (upper quartile point) show that it is less programmatically risky 
than many other approaches for getting cargo to the SSF. It may be noted that 
return cargo from SSF is a significant consideration, and is not off-loaded from 
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the Space Shuttle in this architecture. Architecture 4 adds the additional 
programmatic risk of developing the RPC and CRV to that already in 
Architecture 3. This results in its ranking only slightly above the median point 
(0.563 to 0.573 scores). Inherent to the concept of providing Alternate Access is 
the development of one or more new systems, which will infallibly increase the 
programmatic risk over continued use of a mature system. 

e. Launch Schedule Confidence - Architecture 3 consistently runs at slightly better 
than half of the LSC associated with the reference architecture. Architecture 4, 
with its heavy dependence upon ELV operations and facilities, initially 
compares favorably with the reference architecture, and surpasses it as the flight 
rate increases to the maximum in "If" E-High. Although it may appear from a 
cursory examination of Table 3.3.7.4-1 that Alternate Access increases the LSC 
Attribute when going from "If" B to C, the effect is really due to changes in the 
numbers of Space Shuttle flights. In Architecture 1, the number of such flights 
more than doubles, causing a decrease in LSC. Conversely, the number of Space 
Shuttle flights goes down in Architectures 3 and 4 - and total (mostly ELV) 
flights increase by only 31 to 46 percent, resulting in greater LSC. 

f. Environment — Most of the environmental benefit of Architecture 3 over 
Architecture 1 comes from the substitution of all-liquid NLS vehicles for the 
solid-boosted Titan IV vehicles. The elimination of a few Space Shuttle flights 
that were for cargo delivery only provides an additional increment. This is all 
irrelevant from the standpoint of Alternate Access. 

Architecture 4 is still an improvement over Architecture 1, but suffers due to 
the greater total number of vehicles launched. This is a result of changing the 
manifesting philosophy, not the provision of Alternate Access, to which it is 
irrelevant. 
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3.3.8 Separation of People and Cargo - Architecture Options 5. 6 and 7 


3.3.8. 1 Description of the Considerations 

The principal consideration addressed by this group of architectures is whether the 
attributes of a transportation architecture improve or worsen by separating people 
from cargo for transportation to and from low Earth orbit. In the wake of the 
Challenger accident, it was determined that the Space Shuttle should no longer carry 
satellite payloads which did not require human presence, to reduce the chance of 
another crew loss - that is, to improve safety. 

But separating people completely from cargo carries penalties as well. It reduces the 
flexibility of a human-tended system to carry out some sortie science and satellite 
servicing missions. It mandates cargo transportation without humans to and from SSF, 
requiring autonomous rendevous and docking systems and return systems. And it 
may impair the utilization of the multiple systems needed through manifesting 
inefficiencies. 

The NIT devised Architectures 5, 6 and 7 to test these hypotheses by determining the 
effect on all the study attributes - but especially on Human Safety, PMS, and Funding 
Profile - of separating people from cargo or keeping them together. 

The team made a careful distinction between two types of cargo: untended cargo, 
which does not require people either during transportation or at its destination (i.e., 
untended scientific satellites); and "People at Destination" cargo, which does not 
require people during transportation but does require them at its destination (i.e., SSF 
logistics). Untended cargo is not carried with people in any of these architectures. 
"People at Destination" cargo is the category being tested; it is carried with people in 
some architectures, separated from them in others. 

Comparing these three architectures with Architecure 1, the Reference Architecture, 
permits a second important consideration to be addressed. Does it pay to replace the 
Space Shuttle with a near-term, existing-technology personnel carrier? Architectures 5, 
6, and 7 address this by phasing Space Shuttle out soon after 2000. 

Both considerations will be addressed in this section. 


3.3.8.2 Description of the Architectures 

Architecture 5 keeps people and cargo together. The personnel carrier used is the CLV, 
a winged vehicle with an internal cargo capacity of 15 000 lbs. This gives the CLV the 
capability to accomplish pressurized logistics resupply for SSF, and (with mission kits) 
to conduct science sortie and satellite servicing flights as well. The CLV is launched on 
the MLS-HL. 
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Architecture 6 separates people from cargo completely. Its personnel carrier, the 
Boeing-developed PLS, a biconic, which is used in many other architectures, can carry 
only crew and their "luggage". It is launched on the smaller MLS-50. Cargo is 
launched separately in a CRV with a capacity of 40 000 lbs, on an MLS-HL. 

Since the PLS has no cargo capability, science sortie and servicing missions must be 
carried out differently than in Architecture 5. Sortie missions are accomplished by 
rendezvousing and docking the personnel carrier with a separately launched science 
payload. Satellite servicing requires that the personnel carrier and the servicing 
hardware be separately launched, rendevousing first with each other, then with the 
satellite to be serviced. 

Architecture 7 launches people and cargo "in tandem" as separate payloads on the 
same booster when both have the same destination. Its features are: 

• The same people-only PLS is used as in Architecture 6. 

• The PLS is launched on the MLS-HL, and the excess capacity of that booster is 
used to launch cargo on the same launch. The cargo is launched in a Logistics 
Return Vehicle (LRV) with a cargo capacity of 15 000 lbs. 

• The PLS has full-abort-coverage independent of the cargo. 

• The logistics return vehicle (LRV) is transported to SSF (or to a satellite requiring 
servicing) by the PLS, and returns independently. 

These arrangements permit these three architectures to carry out SSF crew transfer, 
logistics resupply, science sortie, and satellite servicing missions without the Space 
Shuttle. Space Shuttle is phased out early (between 2000 and 2005) in all three 
Architectures. 

Figure 3.3.8.2-1 shows the systems present in each architecture, their functions, and 
their phasing. 


3.3.8.3 Manifesting Philosophy 

Each architecture had special manifesting ground rules as follows. 

For Architectures 5, 6 and 7: 

• All human-tended transportation is carried out by the CLV (5) or the PLS (6, 7). 
This includes the ACRV function. Therefore, the duration of human-tended flights 
to SSF matches the SSF crew rotation period at the time, e.g., 90 days at PMC, 
increasing to 180 days after EMCC. 
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Figure 3.3.8.2-1- Architecture systems, functions, and phasing. 
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• The Space Shuttle is phased out by 2005. 

Architecture 5: 

• Cargo delivery to and return from SSF is carried out by CLV to the extent possible 
on crew rotation missions (this satisfies the pressurized cargo requirement). The 
remaining cargo is carried on the CRV, launched on the MLS-HL. 

Architecture 6: 

• All cargo to and from SSF is carried on the CRV /MLS-HL. 

Architecture 7: 

• Cargo to and from SSF is carried by the LRV to the extent possible on crew rotation 
missions. The CRV /MLS-HL carries any remaining cargo. 


3.3.8.4 Flight Activity 

Table 3. 3.8. 4-1 summarizes the flight activity in these architectures. It excludes those 
flights which are invariant across all architectures: the NASA Mixed Fleet Manifest 
(1992-199 7), DOD flights, and west coast flights. Architecture 1, the Reference 
Architecture, is shown for comparison. 

Some of the flights in the table can be ignored in this evaluation, because they do not 
carry crew, and are constant across all architectures. They are: 

• Atlas and Delta flights (columns 6 and 7 in the table). 

• A group of 41 flights comprising the Titan IV /Centaur flights (column 8), MLS-X 
flights (column 9), and 26 of the MLS-HL flights in column 10. 

The rest of the table will be used to compare and explain the differences in architecture 
scores. 
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TABLE 3.3.8.4-1.- FLIGHT ACTIVITY: ARCHITECTURES 1, 5, 6 AND 7 
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MLS- 

HL 

RPC 

+LRV 

Atlas 

HAS 

Delta 

n 

Titan 

IV/C 

MLS- 

X 

MLS- 

HL 

Total 

Human 

Flights 

Egg! 

IF A 












1 

38 




23 

35 

41 

0 

0 

38 

137 

5 

9 

29 



23 

35 

El 

8 

26 

38 

137 

6 

7 


31 


23 

35 

mM 

8 

57 

38 

168 

7 

9 



29 

23 

35 

MM 

8 

26 

38 

137 

1 if £3/11 

■ I 











1 

1 

0 



23 

35 

41 

0 

0 

76 

175 

1 

SB 

115 



23 

35 

'mm 

8 

26 

130 

229 

.19 

12 


81 


23 

35 

H 

8 

107 

93 

273 

MM 

14 



159 

23 

35 

MM 

8 

26 

173 

272 

IF C 












1 

219 

0 



23 

35 

41 

0 

0 

219 

318 

5 

48 

195 



23 

35 

mm 

8 

26 

243 

342 

6 

42 


165 


23 

35 

S;./l 

8 

235 

207 

515 

7 

46 



227 

23 

35 

MM 

8 

153 

273 

499 













Mm 

257 

0 



23 

35 

41 

0 

0 

257 

356 

KB 

58 

225 



23 

35 

mm 

8 

26 

283 

382 

Mm, 

41 


166 


23 

35 


8 

295 

207 

575 

MM 

46 



227 

23 

35 

H 

8 

205 

273 

551 

ELo 












1 

276 

0 



23 

35 

41 

0 

0 

276 

375 

5 

58 

244 



23 

35 

WM 

8 

26 

302 

401 

6 

41 


185 


23 

35 

mm 

8 

295 

226 

594 

7 

46 


19 

227 

23 

35 

Hi 

8 

205 

292 

570 

E Hi 












1 

308 

0 



23 

35 

41 

0 

0 

308 

407 

5 

58 

276 



23 

35 

mm 

8 

26 

334 

433 

6 

41 


217 


23 

35 


8 

295 

258 

626 

7 

46 


51 

227 

23 

35 

mm 

8 

205 

324 

602 


3.3-196 


Rev. E 












































































3.3.8.5 Attribute Values and Scores 


Table 3.3.8.5-1 summarizes the attribute scores for these Architectures. Note the 
following features of the table: 

• Weighting percentages used to derive total architecture scores are shown at the top 
of the table. 

• The Funding Profile columns list the scores for its two subattributes: total cost and 
peak-year cost. The Funding Profile score is the average of these two, weighted 
equally. 

• The Human Safety columns list the raw values of the attribute, which are the 
number of spacecraft losses over the span of the architecture, as well as the score. 

• The PMS columns list the raw value of the attribute, as well as the score. 

• Raw or subattribute values are not shown for the other attributes. They are less 
significant to the evaluation. 

The "Score" in the last column is the total score for the given architecture and "If' 
scenario - that is, the average of the individual attribute scores weighted according to 
the percent weightings shown at the top of the chart. 

These scores will differ significantly if different weights are assigned. For example, if 
Funding Profile is given 100 percent weight. Architecture 1 scores highest. 
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TABLE 3.3.8.5-1- ATTRIBUTE SCORES FOR ARCHITECTURES 1, 5, 6 AND 7 



ACR 

Env 

Funding Profile 

Human 

Safety 

PMS 

LSC 

Score 

W$t: 

13% 

4% 

27% 

29% 

19% 

8% 

100% 




| Total 

Peak 

Score 

Losses Score 

Value Score 



IF A 











1 

1.000 

0.000 

0.234 

1.000 

0.679 

1.700 

0.100 

0.932 

0.133 

0.532 

41.02 

5 

0.639 

0.996 

0.377 

0.293 

0.341 

0.900 

0.900 

0.947 

0.967 

0.254 

68.00 

6 

0.539 

1.000 

0.238 

0.000 

0.082 

0.800 

1.000 

0.947 

1.000 

0.063 

61.73 

7 

0.562 

0.996 

0.377 

0.482 

0.455 

0.900 

0.900 

0.947 

0.967 

0.185 

69.53 

1 IF B 











1 

1.000 

0.100 

0.308 

0.998 

0.740 

3.300 

0.435 

0.933 

0.179 

0.656 

54.64 

5 

0.622 

0.994 

0.229 

0.301 

0.300 

2.400 

0.826 

0.947 

0.967 

0.344 

65.24 

6 

0.529 

1.000 

0.000 

0.000 

0.000 

2.000 

1.000 

0.948 

1.000 

0.123 

59.86 

7 

0.525 

0.993 

0.013 

0.078 

0.052 

2.700 

0.696 

0.948 

0.989 

0.022 

51.35 

IF C 











1 

1.000 

0.283 

0.679 

1.000 

0.929 

6.700 

0.150 

0.935 

0.259 

0.409 

51.76 

5 

0.681 

0.992 

0.405 

0.338 

0.412 

3.800 

0.875 

0.948 

0.894 

0.213 

68.01 

6 

0.674 

1.000 

0.294 

0.189 

0.268 

3.300 

1.000 

0.949 

0.926 

0.131 

67.64 

7 

0.612 

0.993 

0.208 

0.191 

0.221 

4.000 

0.825 

0.949 

0.917 

0.000 

59.24 

i IF D 











1 

1.000 

0.280 

0.678 

1.000 

0.921 

7.600 

0.104 

0.935 

0.265 

0.351 

49.85 

5 

0.682 

0.968 

0.338 

0.359 

0.383 

4.200 

0.813 

0.949 

0.861 

0.162 

64.31 

6 

0.675 

1.000 

0.246 

0.166 

0.226 

3.300 

1.000 

0.949 

0.891 

0.093 

65.55 

7 

0.613 

0.991 

0.178 

0.192 

0.203 

4.000 

0.854 

0.949 

0.883 

0.000 

58.96 

IF 

ELOW 










1 

1.000 

0.244 

0.690 

1.000 

0.927 

8.000 

0.132 

[ 0.935 

0.267 

0.327 

50.52 

5 

0.685 

0.969 

0.351 

0.359 

0.388 

4.300 

0.830 

0.949 

0.843 

0.169 

64.70 

6 

0.680 

1.000 

0.225 

0.166 

0.239 

3.400 

1.000 

0.950 

0.873 

0.098 

65.66 

7 

0.618 

0.991 

0.208 

0.192 

0.218 

4.100 

0.868 

0.949 

0.860 

0.000 

59.40 

1 IF E HIGH 










1 

0.999 

0.171 

0.646 

0.933 

0.867 

8.700 

0.000 

0.935 

0.275 

0.270 

44.47 

5 

0.679 

0.967 

0.310 

0.359 

0.366 

4.500 

0.792 

0.949 

0.852 

0.136 

62.82 

6 

0.675 

0.998 

0.225 

0.166 

0.213 

3.600 

0.962 

0.950 

0.877 

0.082 

63.74 

7 

0.614 

0.989 

0.162 

0.192 

0.193 

4.300 

0.830 

0.949 

0.869 

0.002 

57.75 


The two following figures show the total scores graphically. Figure 3.3.8.5-1 shows the 
total scores for Architectures 1, 5, 6 and 7. Figure 3.3.8.5-2 shows the total scores for all 
Architectures, to illustrate how these Architectures ranked with the others in the study. 
Note that only Architecture 8 ranked higher than 5, 6 and 7. Architecture 1 is in the 
middle range of the group. 
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Figure 3.3.8.5-1- Total scores for Architectures 1, 5, 6 and 7. 
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3.3.8.6 Findings 

This section will describe and explain the significant differences between Architectures 

1. 5. 6 and 7 in flight activity and Attribute scores. These findings will be used in the 
subsequent sections to analyze the two considerations. 

Note from the figures above that the relative rankings of these architectures do not 
vary much with increasing flight activity; they are quite stable across the "If" scenarios. 
Since no changes of significance appear above "If" C, "If" C is used as an example in 
most of the findings. 

3.3.8.6.1 Flight activity .- Referring to Table 3.3.8.4-1, and taking Architecture 1 as the 
baseline for comparison, the other architectures show the following significant 
differences across the period of the study. 

• Architecture 5: 

Finding - Human flights increase moderately (from 219 to 243 in "If" C). Total 
flights increase by about the same number as human flights. 

Rationale - The smaller cargo capacity of the CLV compared to the Space Shuttle 
results in more flights being required to conduct science sortie missions. These 
Spacelab-type missions are broken into smaller pieces for flight on CLV. 

• Architecture 6: 

Finding - Human flights decrease slightly (from 219 to 207 in "If' C). 

Rationale - In Architecture 1, an occasional extra Space Shuttle flight is required 
for SSF logistics. In Architecture 6, logistics flights do not carry crew; only the 
minimum number needed for crew rotation are flown to SSF. 

Finding - Total flights increase greatly (from 342 to 515 in "If' C). 

Rationale - (1) Sortie science missions require two flights each, one of the PLS 
and one for the science payload to rendevous with the PLS, (2) satellite servicing 
missions also require two flights each, and (3) the PLS crew rotation flights to SSF 
carry no cargo; they must be flown in addition to the same number of CRV cargo 
flights as are flown by the Space Shuttle in the baseline. 

• Architecture 7: 

Finding - Human flights increase substantially (from 219 to 273 in "If" C). 

Rationale - More sortie science launches are required. The LRV, used to carry the 
science payload in tandem with the PLS (on the same booster), has only 15 000 lbs 
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gross capacity compared to Space Shuttle's 40 000 lbs, and has a lower "packaging 
efficiency" than the 15 000 lb cargo CLV used in Architecture 5. Four or five more 
flights per year are thus needed after 2005. 

Finding - Total flights are greatly increased (from 318 to 499 in "If" C). 

Rationale - (1) As in Architecture 6, the crew rotation flights to SSF must be 
augmented by additional cargo flights. The added flights are not as many as in 
Architecture 6 because the crew rotation flights carry some cargo in the LRV, and 
(2) there are more human flights, as explained above. 

• Comparing Architectures 5, 6 and 7: 

Table 3.3.8.6-1 contains a summary of flight activity in Architectures 5, 6 and 7 
("If'C). 


TABLE 3.3.8.6-1- FLIGHT ACTIVITY: ARCHITECTURES 5, 6 AND 7 


Architecture 

Human Flights 

Totcil Flights 

5 

243 

342 

6 

207 

515 

7 

273 

499 


3.3.8.6.2 Attribute Scores 

This section will state and explain the significant differences in attribute scores 
between these architectures. 

The two most important attributes are Cost (Funding Profile) and Human Safety. The 
ACR is closely related to cost, and PMS to Human Safety. 

The following two figures show the scores of these architectures in Cost and Human 
Safety. These attributes sharply distinguish Architectures 5, 6 and 7 from 
Architecture 1. 
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Funding Profile Scores 



Figure 3.3.8.6-1.- Cost scores of Architectures 1, 5, 6 and 7. 


Safety Scores 


■ iFA ■ IFB BlFC UlFD EllFELOW □ IFEHIGH 



Figure 3.3.8.6-2- Human safety scores of Architectures 1, 5, 6 and 7. 


a. Funding Profile - The following table shows the actual Funding Profile values for 
Architectures 1, 5, 6 and 7 in "If" C. This data is shown because, although the 
differences are substantial, the attribute scores shown in Figure 3.3.8.6-1 above 
exaggerate them somewhat. 
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TABLE 3.3.8.6-2- ARCHITECTURE COST COMPARISON 



UNWRAPPED 

WRAPPED 1 


m 


Unrel’ 

Total 

Peak 



Unrel’ 

Total 

Peak 

Arch 1 

25.1 

136.8 

14.3 

176.2 

7.3 

26.3 

137.0 

14.3 

177.6 

7.3 

Arch 5 

28.5 

118.0 

9.4 

155.9 

9.8 

51.0 

156.9 

9.4 

217.3 

13.1 

Arch 6 

21.0 

138.8 

7.8 

167.6 

10.6 

37.3 

188.1 

7.8 

233.2 

14.3 

Arch 7 

22.5 

144.6 

10.2 

177.3 

10.5 

40.1 

195.4 

10.2 

245.7 

14.3 


Comparing Architectures 5, 6 and 7: 

Finding - Architecture 7 has the highest total cost. 

Rationale - (1) It has many more human and total flights than Architecture 5, (2) it 
has many more human flights than Architecture 6 (these are flown on the heavier 
and more costly MLS-HL, compared to Architecture 6's human flights on the MLS- 
X), and (3) it has a higher unreliability cost (the cost of replacing vehicles lost in 
accidents) than Architecture 6 because of its lower safety score. 

Finding - Architecture 5 has the lowest total cost. 

Rationale - It has many fewer total flights. This more than compensates for the 
higher DDT&E cost of developing the CLV. 

Comparing of Architecture 5 with Architecture 1: 

Finding - Architecture 1 total cost is 19 percent lower ($177.6B vs. $217.3B). 

Rationale - (1) Architecture 1 has no DDT&E cost for new systems, (2) it has fewer 
total flights, and (3) a larger proportion of its hardware is reusable, lowering 
recurring costs. (CLV is reusable, but the MLS-HL is completely expendable 
including all engines). 


b. Human Safety.- The estimated number of crew loss events, which determines the 
Human Safety score, is a function-of-probability of a catastrophic failure during as- 
cent (the reciprocal of the PMS attribute), the probability of an unsuccessful abort, 
and the number of flights. 

Comparing of Architectures 5, 6 and 7: • 

Finding - Architecture 6 has the best Human Safety score. 
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Rationale - (1) Architecture 6 has the fewest human flights, and (2) the PMS score 
for the Architecture 6 human booster, the MLS-X, is slightly higher than for the 
MLS-HL used in 5 and 7 (the MLS-X has no upper stage). 

Finding - The Human Safety scores of Architectures 5, 6 and 7 are not significantly 
different. The raw scores are 3.8, 3.3 and 4.0 respectively, well within the error 
margin for the study. 

Rationale - Architecture 5, 6 and 7 human systems all have engine-out 
capability throughout the launch profile. They all have very low probabilities of 
unsuccessful abort because they are designed with Launch Escape Systems (LES), 
and with the people well separated from the engines. 

Comparing of Architectures 5, 6 and 7 with Architecture 1: 

Finding - All three of the new architectures have significantly better 
safety scores than Architecture 1. 

Rationale - (1) The Space Shuttle has a lower PMS (0.935 versus 0.948 for 
Architecture 5) because of the gaps in its engine-out capability, and (2) Space 
Shuttle has a lower probability of successful abort because it was not designed 
with a full LES, and because of the proximity of the SRB's and SSME's to the crew. 


3.3.8.7 Conclusions - First Consideration 

• Should people and cargo travel together or separately? (Architectures 5 versus 6 
versus 7) 

Architecture 5 transports people and cargo together (as does the Space Shuttle in 
Architecture 1). Architecture 6 separates them completely. Architecture 7 
represents a hybrid solution, launching both on a single booster but with 
independent abort and return capability, an attempt to evaluate reducing the 
number of launches required. 

- Summary of Findings 

Finding 1 - Right activity. Architecture 5 has the fewest total flights. 
Architecture 6 has the most, but Architecture 7 has almost as many as 6. These 
differences are reflected in the total architecure costs. 

Rnding 2 - Human Safety. Architecture 6 has the highest scores, and 5 is 
slightly better than 7. But all score well, and the raw scores are very close. 
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Finding 3 - Cost. Architecture 5 is best, 6 intermediate, 7 worst. The actual cost 
estimates (see Figure 3.3.8.6-1) are within 13 percent. 

A possible additional consideration is operational complexity. Architecture 5, 
with its cargo capability, can carry out all the missions without rendezvous. 
Architectures 6 and 7 each present SSF with two vehicles to berth each trip; 6 
requires rendezvous to accomplish a science sortie mission, and 7 requires a 
docking maneuver. 

The findings suggest that Architecture 7, the hybrid solution, is not the answer. 
It scored lower than 5 or 6 overall and in every significant attribute. It is more 
expensive and slightly less safe, and it has the most new systems to develop. 

- Conclusions 

Conclusion 1 - If science sortie or satellite servicing missions continue, keeping 
people and cargo together is the preferred solution. 

Conclusion 2 - The PMS can be significantly improved by booster design 
independent of the people-versus-cargo issue. 

Conclusion 3 - Human Safety can be significantly improved by full launch 
escape capability and separation of the people from the main engines, 
independent of the people-versus-cargo issue. 


3.3.8.8 Conclusions - Second Consideration 

• Does it pay to replace the Space Shuttle with a near-term, existing-technology 
personnel carrier? 

- Summary of Findings 

Finding 1 - Architectures 5 and 6 score substantially better than Architecture 1 
overall, given the present attribute weights. 

Finding 2 - Human Safety. The new architectures score much better than the 
baseline. In loss events. Architecture 1 has a 6.7 score, compared to 3.8 for 5, 
and 3.3 for 6 ("If' C) - an improvement by a factor of 2. 

Finding 3 - Cost. The baseline has the lowest costs, both total and peak. 

A possible additional consideration is environmental impact. The new 
architectures score much higher than 1; the Space Shuttle scores poorly because 
of its solid boosters. This was not analyzed in detail because of the low weight 
given to the Environment attribute. 
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Condusions 


Condusion 1 - Repladng the Space Shuttle with a new personnel carrier can 
realize major gains in Safety and Environmental Impact 

Condusion 2 - Repladng the Space Shuttle with a personnel carrier in the near 
term has not been shown to be cost-effective. 
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3.3.9 


Advanced Technology and New Concepts - Architecture 
Options 1, 8, 16, 17, 18, and 19 


3.3.9.1 Description 

The consideration addressed in this section is whether it is appropriate to introduce 
a new human-tended carrier vehicle incorporating advanced technologies. Studies 
in the past few decades have investigated such concepts and considerable potential 
for improvement has been indicated. Typically, these new designs incorporate new 
technology and/or new operational approaches that would result in a significant 
improvement over existing systems with regard to some key attribute. Inclusion of 
these designs in the HTS study was intended to help explore the overall 
architectural potential, including the cost impacts of using new concepts. 

Consequently, seven architectures were defined for assessment, each employing a 
different advanced technology personnel carrier. These carriers spanned a range of 
technologies, and developmental and operational philosophies. The criteria for 
selecting these seven included: (1) the carrier must be representative of a class of 
concepts, and (2) the availability of attribute data for use in this study. The advanced 
technology architectures are numbered 8, 9, 10, 16, 17, 18, and 19. The new concept 
for Architecture 8 is a SSTO vehicle, operable either with or without a crew, that 
includes a plug nozzle and lightweight materials to achieve its performance goals. 

A vertical takeoff, horizontal landing two-stage-to-orbit (TSTO) concept, the AMLS, 
is the centerpiece of Architecture 9. Architecture 10 features an advanced 
airbreathing, horizontal takeoff and landing, NDV SSTO. Architecture 16 features a 
subsonic, air-launched concept, based on the Rockwell AMSC studies. For 
Architecture 17, a personnel capsule, similar in crew size and functionality to the 
RPC /launch vehicle system, called the RUPC is included. By using advanced 
materials, the RUPC's weight is sufficiently low to permit using a smaller, less 
expensive launch vehicle (a HR Titan II with 10 strap-on solid motors). A 
supersonically staged, fully reusable TSTO system, called the Beta II, is featured in 
Architecture 18. Finally, another subsonic ALV concept is used for both personnel 
and cargo flights as Architecture 19. 

Table 3.3.9.1-1 provides key data about the new vehicles of the architectures; the 
reference architecture is included. The new technologies involved are shown, along 
with the performance and implementation dates. Manifesting results are discussed 
in detail below; however, it is relevant to indicate here that the cargo capacity of the 
human-tended carrier has significant effect on the flight rates of the cargo vehicles. 
The resultant typical flight rates of both the personnel and cargo vehicles are shown 
(for mission model "If" C). 
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TABLE 3.3.9. 1-1- KEY CHARACTERISTICS 


Arch. 

No. 

Personnel 

Vehide 

IOC 

Major New Technologies 

Up' Cargo Capacity 
220 nmi 9 28 .5° 

"IFC ty 

personnel 

pica! an 
TIV 

nual flight 
Atlas 

rate 

Delta 

1 

Shuttle 

1981 

• none 

46,000 Ibm 

10 

9 

3 

7 

8 

SSTO 

2000 

• new engine (plug nozzle) 

* composite tanks, blanket TPS 

* lightweight materials 

• lightweight subsystems 

15,000 Ibm 

36 

14 

2 

2 

9 

AMLS 

2005 

• composite tanks, blanket TPS 

• lightweight materials 

• lightweight subsystems 

40,000 Ibm 

18 

13 

2 

3 

10 

NDV 

2010 

• new engine (airbreathing) 

• lightweight materials 

• lightweight subsystems 

18,000 Ibm 

28 

13 

2 

3 

16 

AMSC 

2005 

• new engine 

• air launch (M ■ 0.7) 

5,000 Ibm 

24 

25 

3 

7 

17 

RUPC 

2000 

• lightweight materials 

• lightweight subsystems 

1,000 Ibm 

12 

36 

3 

7 

18 

BETA 

2005 

• air launch CM « 5.5) 

• new aiibreathing engine 

• lightweight materials 

18,500 Ibm 

29 

13 

2 

3 

19 

ALV 

2000 

• air launch (M ■ 0.8) 

* recoverable propulsion mod. 

18.400 Ibm 

11 

22 

1 

0 


The performance capabilities, turnaround times, and development and operational 
costs of the advanced technology vehicles are primarily provided by the companies 
and agencies which developed the concepts. The PMS, Human Safety, and ACR 
Attributes were generated on a relative basis, which took into account differences 
between the vehicles in the architectures. However, no assessment or leveling 
between concepts has been made of the relative degree of technical conservatism 
used in design, in estimation of system weights (including provision for weight 
growth and unknowns), and in the estimation of operational characteristics and 
costs. In most cases, new concepts either lacked the detailed definition, or were not 
to be communicated to the NIT, to ensure complete accuracy when assessing 
attributes. As the estimates of any new technology system's capabilities and costs are 
the least reliable part of any architecture analysis, conclusions must be considered 
only point assessments with a wide range of potential variability. In the course of 
this study, limited resources determined the level to which input data could be 
normalized, with respect to each other. Thus, direct comparison of, for example, a 
rapid turnaround SSTO with an ambitious propellant mass fraction to a RUPC 
capsule atop an ELV is difficult. The designs example used for this study are just 
that - examples. 
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It was not the intent of this architectural analysis to provide an answer to the 
question of what the "best" new concept might be. The issue is whether new 
technologies have merit sufficient to warrant their incorporation into potential 
architecture options. 


33.9.2 Manifesting Philosophy 

In each of the seven architectures considered here, the Space Shuttle is phased out 
and the new concept is phased in to become the sole method of transporting people 
up to orbit. The Space Shuttle flights are complete before 2005 in Architectures 8, 17 
and 19. Space Shuttle is phased out before 2010 in Architectures 9, 10, 16 and 18. In 
all seven cases, the ACRV is used for emergency crew return capability from SSF. 
After Space Shuttle phase-out, the ACRV is launched on another vehicle. 

Cargo-up and-down capability is provided by the new element (although never 
exclusively for "up" payloads) in Architectures 8, 9, 10, and 18. In Architectures 16, 
17 and 19, cargo down is provided by using an LRV. In all architectures except for 9, 
cargo-up capability is provided by the Delta, Atlas, and Titan CTF fleet (except in 
Architectures 8, 10, 17 and 19, where this is no need for the Atlas/Delta CTF). 


3.3.9.3 Manifesting Results 

A summary of the total number of flights by each vehicle type is given in Table 
3.3.9.3-1. Note the differences in the percentage of flights that have crews; 
architectures that score well (e.g., in Funding Profile) significantly reduce the 
number of ELV flights. 

The SSTO of Architecture 8 operates both with and without a crew. Table 3.3.93-2 
summarizes each type of flight for each mission model. 


33.9.4 Architecture Evaluation 

33.9.4.1 Attribute summary .- Table 33.9.4-1 summarizes the attribute scores for the 
reference architecture and the seven advanced technology architectures. The study 
consensus attribute weightings are shown at the top of the columns for information. 
The architecture score is shown in the last column; a higher score is better than a 
lower one. ACR and Funding Profile scores for Architecture 9 are not available due 
to lack of cost data for the AMLS. 
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TABLE 3 .3.9 .3-1.- TOTAL FLIGHTS BY VEHICLE TYPE FOR 
ARCHITECTURES 8, 9, 10, 16, 17, 18, AND 19 



3.3-210 


Rev. E 











































































If 


Type Personnel 


Cargo-only 


Total 







■ 

NASA 

31 

42 

73 

1 1 

DoD 

21 

70 

91 

1 

WTR 

0 

27 

27 

■ 

Total 

52 

139 

191 


NASA 

170 

42 

212 

B 

DoD 

21 

70 

91 


WTR 

0 

27 

27 


Total 

191 

139 

330 


NASA 

253 

307 

560 

C 

DoD 

21 

70 

91 


WTR 

0 

27 

27 



Total 

274 

404 

678 


NASA 

253 

403 

656 

D 

DoD 

21 

70 

91 


WTR 

0 

27 

27 


Total 

274 


774 


NASA 

272 

403 

675 

EL 

DoD 

21 

70 

91 


WTR 

0 

27 

27 


Total 

293 

500 

793 


NASA 

304 

403 

707 

EH 

DoD 

21 

70 

91 


WTR 

0 

27 

27 

i 

Total 

325 

500 

825 



















































TABLE 3.3.9.4-1- NEW CONCEPTS/TECHNOLOGY ARCHITECTURES 

ATTRIBUTE SCORING 


"If" 

Arch. 

ACR 

Env. 

FP 

Safety 

LSC 

PMS 

Arch. 



13% 

4% 

27% 

29% 

8% 

19% 

100% 


i 

1.000 

0.000 

0.703 



0.538 

54.3 


8 

0.565 

0.437 

1.000 


0.309 

1.000 

MEM _ 


9 

N/A 

0.320 

N/A 

0.692 

0.090 

0.747 

N/A 


10 

0.000 

0.154 

0.391 


1.000 

0.000 

27.3 

A 

16 

0.850 

0.257 

0.686 

0.769 

0.576 

0.769 

61.1 


17 

0.617 

0.058 

0.894 

0.769 

0.669 

0.769 

mm 


18 

0.136 

0.277 

0.000 


0.000 

0.308 

19.2 


19 

0.437 

0.526 

0.814 

0.646 

0.396 

0.846 

62.1 


1 

1.000 

0.100 

0.754 

0.550 

0.428 

0.550 

57.0 


8 

0.545 

0.567 

1.000 

0.800 

0.290 

0.800 

79.9 


9 

N/A 

0.481 

N/A 

0.800 

0.145 

0.780 

N/A 


10 

0.000 

0.305 

0.430 

0.015 

1.000 

0.150 

34.2 

B 

16 

0.776 

0.407 

0.671 

0.000 

0.279 

0.000 

46.6 


17 

0.568 

0.000 

0.769 

0.600 

0.651 

0.600 

50.8 


18 

0.107 

0.391 

0.089 

0.450 

0.000 

0.450 

27.5 


19 

0.469 

0.408 

0.531 

0.650 

0.424 

0.650 

47.3 


1 

1.000 

0.283 

0.931 

0.172 

0.239 

0.172 

54.3 


8 

0.478 

0.685 

1.000 

0.862 

0.333 

0.862 

82.6 


9 

N/A 

0.578 

N/A 

0.759 

0.209 

0.721 

N/A 


10 

0.000 

0.417 

0.600 

0.000 

1.000 

0.000 

35.6 

C 

16 

0.683 

0.261 

0.595 

0.207 

0.424 

0.207 

44.6 


17 

0.657 


0.592 

0.621 

0.655 

0.621 

47.7 


18 

0.060 

0.491 

0.327 

0.172 

0.013 

0.172 

27.2 


19 

0.605 

0.311 

0.465 

0.621 

0.488 

0.621 

45.6 


1 




0.293 

0.253 

0.293 

58.3 


8 


0.701 


0.878 


0.878 

83.4 


9 

N/A 

0.581 

N/A 

0.732 


0.756 

N/A 


10 



Hi 




36.8 

D 

16 


0.229 

WBm 

0.366 


0.366 

48.0 


17 







49.5 


18 


0.487 


0.195 


0.195 

26.5 


19 


0.254 


0.732 


0.732 

47.1 


1 

1.000 

0.244 

0.931 

0.311 

0.244 


59.1 


8 

0.501 

0.705 

1.000 

0.889 

0.343 

0.889 

83.5 


9 

N/A 

0.583 

N/A 

0.756 

0.223 

0.759 

N/A 


10 

0.014 

0.394 

0.614 

0.067 

0.989 

0.067 

38.9 

E low 

16 

0.695 

0.231 

0.599 

0.422 

0.451 

0.422 

50.2 


17 

0.670 

0.006 

0.573 

0.711 

0.668 

0.711 

50.1 


18 

0.072 

0.484 

0.278 

0.267 

0.016 

0.267 

29.3 


19 

0.636 

0.261 

0.424 

0.756 

0.532 

0.756 

48.4 


1 

1.000 

0.171 

0.869 


0.205 

0.200 

54.3 


8 

0.498 

0.703 

1.000 

0.867 

0.338 

0.867 

83.1 


9 

N/A 

0.580 

N/A 

0.733 

0.229 

0.801 

N/A 


10 

0.000 

0.373 

0.610 

0.000 

1.000 

0.000 

37.2 

E high 

16 

0.693 

0.229 

0.598 

0.378 

0.473 

0.378 

49.6 


17 

0.668 

0.000 

0.566 

0.667 

0.666 

0.667 

48.9 


18 

0.048 

0.475 

0.231 

0.222 

0.000 

0.222 

26.5 


19 

0.632 

0.261 

0.406 

0.689 

0.523 

0.689 

46.2 
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33.9.4.2 Final scoring - Figure 33.9.4-1 shows the overall scoring of all the 
architectures for "If C". Three of the advanced technology architectures score well 
(16, 17, and 19), but of them only Architecture 8 (the SSTO) was significantly 
improved. Architecture 9 could not be scored at this time as cost data was 
unavailable. Architectures 10 and 18 scored poorly, largely due to their respective 
low score for ACR. 


100 


90 -I- 




1 8 10 16 17 18 19 

Architecture 


Figure 33.9.4-1- Architecture scores, "If" C. 

33.9.43 Analysis of scores and consideration .- Figure 33.9.4-2 provides a ready 
comparison of the relative scoring of the seven advanced technology architectures 
and of the reference architecture (Architecture 1) for mission model "If" C. The 
attribute weighting (e.g., safety weighting is 29 percent) is noted on each of the 
columns. 

a. Human Safety - Observations concerning the scoring include: 

(1) All of the advanced technology architectures would enhance human flight 
safety, 

(2) The current personnel system, the Space Shuttle, is less safe than other 
potential personnel carriers. 


B Arch Cost Risk 
B Environment 

□ Funding Profile 

□ Humin Safety 

O Launch Sched Conf 
B Prob of M« Sucoeee 
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(3) The SSTO and the RUPC provide the greatest safety increases. However, the 
safety attribute scoring indicates that the greatest increase in safety would be 
provided by other architectures (such as CLV or RPC launched by versions 
of the MLS), and 

(4) It is apparent that Human Safety could be increased, although none of the 
advanced technology vehicles assessed may be the best choice. Figure 
3.2.3.3-1 shows safety-relevant features for all the human-rated systems, 
including the advanced technology launch systems, and offers some insight 
as to why different concepts score well. 

The RUPC has safety features similar to those of the RPC in that it features a full 
launch escape system (not merely ejection seats) and humans are in a separate 
unit from the main propulsion engines. However, the booster involved (Titan 
n with 10 solid strap on motors) does not have the safety features of the MLS (all 
liquid with full shut down capability and engine-out). 

b. Funding Profile - The non-recurring costs of the architectures of interest are 
compared in Figure 3.3.9.4-3. The cost elements are the preplanned product 
improvement P 3 I and "other" composed of such items as vehicle development 
costs (for new engines, structure, software, ground systems, etc.) and facilities 
costs. Note that there is an approximate five-to-one ratio between the highest 
and lowest non-recurring cost estimates. The Space Shuttle or the reference 
architecture (Architecture 1 has effectively no development costs (they are 
sunk), but only P 3 I costs as shown. Two of the above architectures employ 
person-carrying modules launched by expendable boosters. In Architecture 17, 
the RUPC is launched by a modified Titan II employing solid, strap-on boosters. 
The development cost contributions of these human-carrying vehicle elements 
are RPC, $3.01B and RUPC, $1.43B. The remaining advanced technology vehicle 
development costs are: SSTO, $2.71 B; AMSC, $6.47B; Beta, $15.54B, NDV, $12.5B, 
ALV, $3.8B; AMLS cost data was not available. 
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Figure 33.9.4-2 - Advanced technology architectures compared by attribute 
(shown for "If” C). 
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( 17 ) 


Figure 3.3.9.4-3 - Non-recurring costs compared ("If C). 


The recurring cost per flight of the various vehicles is, of course, a major 
contribution to the total architecture cost (through the year 2020). The average 
cost- per-flight (for the full time period) for the advanced technology 
architectures and two others is shown in Figure 3.3.9.4-4. These costs are related 
to a specific operations flow and an operating philosophy that may or may not 
be comparable between concepts. 



2 

at 


Figure 3.3.9.4-4 - Average cost per flight of human rated vehicles ("If' C). 
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Visibility of the contributions of the non-recurring and recurring costs can 
enhance understanding of the total architecture costs. These totals are shown in 
Figure 3.3.9.4-5. This figure also shows the effects of other factors on the total 
costs; for example, it is evident that the payload capabilities of the AMSC and 
RUPC force a large number of flights onto the major cargo vehicle (such as Titan 
IV) of the architecture. The Space Shuttle cost contribution is low in 
Architectures 8, 17, and 19 because Space Shuttle phase-out begins in 2000, not in 
2005 as in Architectures 16 and 18, or 2010 as in Architecture 10. Costs in the 
figure that are not included in either the Space Shuttle, new vehicle, or Titan, 
are grouped as "other" (this category would include Delta, Atlas, LRV's, etc). 

The above costs, along with annual peak funding, contributed to the cost 
attribute scores that were shown in Figure 3.3.9.4-2. 


250 T 



1 8 10 16 17 18 19 


Architecture Number 

Figure 3.3.9.4-5 - Components of total architecture cost for "If" C. 


c. Probability of Mission Success - Architecture 8 (SSTO) scores well above both 
the reference architecture and the other advanced technology architectures. The 
SSTO has high estimated reliability and flies many of the cargo-only missions. 
Conversely, the NDV requires that many missions in Architecture 10 be flown 
by the Titan IV (due to the requirement for heavier payloads than the SSTO can 
accommodate), which has a relatively low system PMS, so that overall PMS is 
reduced. The PMS scores for Architectures 16, 17, 18 and 19 are more strongly 
driven by the increases they cause in ELV flight rates than by their own 
reliability characteristics. 
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d. Architecture Cost Risk - Intuitively, one might expect any new concept 
architecture involving new technology to score poorly in the risk attribute. In 
fact, only Architectures 18 (Beta) and 10 (NDV) scored very low. This is 
primarily due to the cost- weighted nature of the attribute definition; the high 
non-recurring cost of the Beta system resulted in a high risk value. The 
Technical Challenge subattribute also worked against the SSTO of Architecture 
8, but, in accordance with cost estimates used in this study, it was not weighted 
as heavily as the Beta or NDV. Similarly, the Program Immaturity subattribute 
penalized the new concept architectures, but the systems with higher estimated 
systems cost (such as the Beta and NDV) lost ground relative to the other 
architectures as the cost weighting was applied. 

The Number of New System's subattributes seems to have little impact except 
in the case of Architecture 17, where the number of vehicle types in the 
manifest in "Ifs" that do not include SSF are relatively high (the RUPC does not, 
in itself, replace the functional requirements for other launch vehicle types in 
the architecture). 

e. Environment - While many of the advanced technology architecture vehicles 
have relatively little environmental impact, they force additional flights of the 
Titan IV (which has SRB's), due to their limitations in payload performance. 
The RUPC concept not only requires more Titan-IV flights, but itself employs 
solid boosters on the Titan II plus graphite-epoxy motor (GEM) launch vehicle, 
which have a negative impact on the environment score. 

f. Overall Findings - With the possible exception of the SSTO, none of the 
advanced technology architectures appear to offer significant advantage over the 
MLS-boosted architectures (5, 6 and 7) or the Space Shuttle Architecture 1. This 
is based on the summation of weighted scorings of attributes as described in the 
previous paragraphs. The impact of the human-rated vehicles on the flight 
rates of the cargo vehicles in the architectures, and the nature of these cargo 
vehicles, seems to have more impact than does the type of human-rated vehicle 
itself, except with regards to Human Safety (and even here the safety of the 
booster has a large effect). The advanced technologies of the MLS (engine-out, 
all liquid, hold down until all engines are lit, new high-reliability engine, 
redundant avionics, etc.) have a large favorable impact. The results may 
indicate that the best place for new technology may be in the cargo launch 
vehicle, which is also used to boost the personnel vehicle. This allows one set 
of new technology elements to benefit both personnel and cargo only flights. 

Upon further reflection on the attribute scoring that produces a superior 
architecture, one finds that perhaps the method of introducing new 
architectures used in the study is too limited. After all, many informed people 
suspect that some forms of new technology, incorporated appropriately into a 
new architecture, should result in some significant improvement in space 
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transportation. Why then, has it not? One hypothesis is that the score of new 
architectures was adversely affected by introducing new systems in one, large 
step which is difficult for the traffic to justify. 

The limitation of introducing a new system is that we are faced with a no-win 
choice: either (a) introduce a new system as soon as possible with the hope of 
reducing operations costs significantly, while exacerbating poor scores in the 
Funding Profile, because of peak funding, and ACR attributes, or, (b) delay 
introduction, reducing ACR and Peak Funding, but moving the benefits (such as 
lower operations and recurring production costs, safety improvements, schedule 
confidence, and environment) so far in the future that the total architecture 
score (which only runs to 2020) is dominated by the shortcomings of existing 
systems. The only way to break out of this paradox is to propose elements with 
radically reduced costs, which produces questionable results. 

One proposed solution to avoid this dilemma is a phased approach to the 
introduction of new technology. This is not necessarily just evolution or P^I 
derivatives. Interim elements are used to create the funding wedge, reduce the 
risk, prove the technology, etc., to get to the operational system that is desired. 
These interim vehicles are developed with the knowledge that their life cycle is 
purposefully short, and not the end-all solution. There is historical precedence 
for this. One example is the Apollo/Satum program, where several vehicles 
(Gemini, Saturn I, etc.) were developed to provide the program maturity to 
build the ultimate vehicle. 

Why would this approach improve new architecture scores? Many people are 
of the opinion, at the time of this writing, that the total space transportation 
budget for the foreseeable future is likely to remain nearly constant. As such, it 
is imperative for any new system, indeed critical to the idea of proceeding with a 
new system, that the funds for development cannot significantly increase the 
space transportation budget. The interim concepts can be described in general 
terms as ones which could selectively incorporate features that could 
immediately reduce operations costs and/ or stretch key technologies beyond the 
state of the art, but only if they are in the direction of the ultimate system. 
Focusing on other attributes, such as safety improvements, may not be 
warranted over the short life of the interim system. One possible scenario is the 
use of a recoverable engine module to effect immediate reductions in recurring 
production costs and provide for experience in reusable launch vehicle 
hardware. By designing this module using existing engines (SSME's) and using 
ET derivative tankage, the development cost does not have to be as large as a 
completely new vehicle. The savings in operations' costs could be directly 
applied to the development bill of the ultimate vehicle (presuming, of course, 
that the government would not choose to apply those funds elsewhere). 
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New technology has a place in improving space transportation. Within the 
traffic levels envisioned by the HTS study, however, the expense and risk of an 
all-new system is not warranted, given the attributes the NIT has chosen to 
evaluate. 
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3.3.10 ACRV Commonality Architecture Options 11, 12 and 13 

There are two feasible approaches to providing on-orbit Assured Crew Return 
Capability (ACRC). 

The first utilizes a special-purpose "lifeboat" attached to SSF, designed only to return 
the entire SSF crew to Earth in case of a medical or systems problem aboard or a loss 
of Space Shuttle return capability. This is the approach planned today for SSF; the 
vehicle is the ACRV. 

The second utilizes the crew transport vehicle to and from SSF as the "lifeboat", 
leaving it docked to SSF during the crew's stay, available for return on need. This is 
the approach taken by the Russians for MIR crews. It was also utilized by NASA for 
the Skylab program, where the Apollo Command /Service Module remained docked 
to the Skylab Workshop throughout the crew stays. 

The first approach requires funding the development of the lifeboat, its 
transportation to SSF in the Space Shuttle, and its return in the Space Shuttle at the 
end of its operational life, if not used. But a simple vehicle with a long quiescent 
lifetime is feasible, and life cycle costs are therefore low. 

The second approach does not require the development of another personnel 
vehicle. But it imposes the requirement on the human transport vehicle used for 
SSF crew rotation that it be capable of on-orbit stays of up to 180 days (the crew 
rotation time for the SSF EMCC phase,) with attendant increases in complexity and 
cost. 

Architectures 11, 12 and 13 were devised to determine which approach resulted in 
the best architecture, as measured by the HTS attributes. 


3.3.10.1 Description of the Architectures 

All three architectures have the following features in common, to permit the 

differences in approach to ACRC implementation to dominate the results: 

• All retain the Space Shuttle for the full duration of the study (through the year 
2020). All human missions except for SSF crew rotation are performed with the 
Space Shuttle, and all cargo return missions are also performed with Space 
Shuttle. 

• A people-only reusable personnel carrier is utilized for SSF crew, rotation 
missions as soon as it is available (this varies with architecture). The vehicle 
concept used is the Boeing/NASA developed PLS, a biconic — the same vehicle 
used in Architectures 6 and 7. It has no cargo capability. It is launched on the 
NLS-50 (NLS-2) booster. 


3.3-221 


Rev. E 


• All utilize the NLS-50 for some non-SSF, cargo only missions, and for up-cargo 
missions to SSF where there is no return cargo requirement (NLS cargo missions 
require the use of the CTV as the NLS-50' s payload). 

• All utilize the Delta and Atlas boosters for the same missions as in the reference 
architecture (Architecture 1). 

• All phase out the Titan IV booster by 2005, in favor of the NLS-50. 

Architecture 11 achieves ACRC with the PLS only: 

• The PLS is available in the year 2000, and conducts all SSF crew rotation flights 
(4 flights per year for 21 years, a total of 84). 

• There is no dedicated ACRV. The PLS is a long-duration version, capable of 
remaining at SSF for full crew cycles of 90 days (during the PMC phase, "If’ C) up 
to 180 days (during the EMCC phase, "Ifs" D and E). 

Architecture 12 phases the PLS in later: 

• The PLS becomes operational in 2005, and is used for all SSF crew rotation flights 
thereafter (4 flights per year for 16 years, a total of 64). 

• An ACRV is developed, and is utilized for SSF emergency crew return until the 
PLS is available in 2005. It is then phased out. 

• PLS (the long-duration version) is used for SSF emergency crew returns after 
2005, just as it is in Architecture 11. 

• Space Shuttle is used for SSF crew rotation flights between 2000 and 2005. 
Thereafter, it is used as in Architectures 11 and 13. 

Architecture 13 utilizes both PLS and ACRV throughout: 

• PLS is phased-in in 2000 and handles SSF crew rotation flights - 84 flights, the 
same as Architecture 11. But it is a short-duration PLS, designed only for 
missions up to 7 days, and does not remain at SSF with its crew. 

• ACRV is introduced in 2000, and is stationed at SSF thereafter for emergency 
crew return. 

The systems, functions, and phasing in each architecture are shown in Appendix B, 

section B.1.1. 
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Thus, these three architectures permit comparison between a dedicated ACRV and a 
long-duration PLS ( Architectures 13 versus 11), and between early and late 
introduction of the long-duration PLS ( Architectures 11 versus 12). 


3.3.10.2 Flight Activity 

Table 3.3.10.3-1 summarizes the flight activity in these architectures. It excludes 
those flights which are invariant across all architectures: the NASA Mixed Fleet 
Manifest (1992-199 7), DOD flights, and west coast flights. The reference architecture. 
Architecture 1, is shown for comparison. 

Since we are addressing an SSF consideration (crew emergency return), "Ifs" A and 
B are not relevant. And, since the results in "Ifs" D and E do not differ from those 
in "If" C, only "If" C is shown and will be analyzed. 


TABLE 3.3.10.2-1.- FLIGHT ACTIVITY, ARCHITECTURES 1, 11, 12 AND 13, "IF' C 


ARCH. 

Space 

Shuttle 

NLS-50 

PLS 

Atlas 

HAS 

Delta 

n 

Titan 

TV/C 

NLS-50 

CTV 

NLS-50 

AUS 

Total 

Human 

Flights 

Total 

All 

IF C 










1 

219 


23 

35 

41 

0 

0 

219 

318 

11 

198 

84 

23 

35 

10 

79 

31 

282 

460 

12 

201 

64 

23 

35 

7 

79 

34 

265 

443 

13 

205 

84 

23 

35 

10 

79 

31 

289 

467 


The significant differences between architectures are restricted to the number of 
Space Shuttle and PLS flights. (A manifesting anomaly resulted in three Titan 
flights being manifested on NLS-50 in Architecture 12). These differences will be 
explained in the analysis below. 


3.3.10.3 Attribute Values and Scores 

Table 3.3.10.4-1 summarizes the attribute scores for these architectures for "If" C. 
Note the following features of the table: 

• Weighting percentages used to derive total architecture scores are shown at the 
top of the table. 
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• The Funding Profile columns list the raw dollar values for the two 
subattributes: total cost and peak-year cost. The Funding Profile score is the 
average of these two, weighted equally. 

• The Human Safety columns list the raw value of the attribute, which is the 
number of spacecraft losses over the span of the architecture, as well as the score. 

• The PMS columns list the raw value of the attribute as well as the score. 

• Raw or subattribute values are not shown for the other attributes. They are less 
significant to the evaluation. 

The "Score" in the last column is the total score for the given architecture and "If" 
scenario - that is, the average of the individual attribute scores weighted according 
to the percent weightings shown at the top of the chart. These scores will differ 
significantly if different weights are assigned. 


TABLE 3.3.10.3-1.- ATTRIBUTE SCORES, ARCHITECTURES 1, 11, 12 

AND 13, "IF" C 



ACR 

Env 

Funding Profile 

■Ml 

PMS 

LSC 

Score 


13% 

4% 

27% 1 

29% 

19% 

8% 

100% 

■ 

Score 


Total Peak Score 

Losses Score 

Value Score 

Score 

Score 

IFC 


■ 



9HS9 



1 

IBKIIIIIM 

0.283 

173.0 7303 0.931 

4.7 0.172 


0.239 

54.3 

11 

0.787 

0.521 

236.7 14.3 0.228 

4.6 0.207 

0.9552 0.812 

0.201 

41.2 

12 

0.714 

0.519 

231.9 12.1 0.385 

4.6 0.207 

0.9553 0.817 

0.211 


13 

0.709 

0.503 

240.5 14.4 0.204 

■S9Q9 

0.9554 0.822 

0.207 

39.0 | 


3.3.10.4 Findings 

This section will describe and explain the differences between architectures in flight 
activity and in attribute scores. These findings will be used subsequently to analyze 
the consideration. 

3.3.10.4.1 Differences in flight activity . - Finding - PLS flights number 84 in 
Architectures 11 and 13, but only 64 in Architecture 12. 

Rationale - As noted above, PLS is introduced late in Architecture 12; 5 years' crew 
rotation flights to SSF are accomplished by Space Shuttle in this architecture. 
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Finding - Space Shuttle Fights decrease from 219 in Architecture 1 only, to 198-201, 
and 205 in Architectures 11, 12 and 13 respectively. This reduction is much smaller 
than the added number of PLS flights. 

Rationale - Some Space Shuttle flights have been replaced by other vehicles 

• SSF crew rotation flights are accomplished by PLS. 

• Some up-cargo to SSF is accomplished by NLS-50/CTV 

But the total number of Space Shuttle flights to SSF can only be modestly reduced 
because of SSF's large down-cargo requirements, which can only be accomplished by 
Space Shuttle. 

Finding - Three more Space Shuttle flights are required in Architecture 12 than in 
11, and four more are required in Architecture 13 than in 12. 

Rationale - These flights are ACRV rotation flights. The study manifest does not 
have any actual "emergency return" ACRV flights. Every 5 years, the ACRV at SSF 
is returned in the Space Shuttle for overhaul, and another ACRV is launched. 

3.3.10.4.2 Differences in attribute scores - Finding - There is no significant 
difference between Architectures 11, 12 and 13 in the foilwing attributes: ACR, 
Environment, Human Safety, PMS, and LSC. 

Rationale - All three architectures utilize the same systems (except for the absence 
of an ACRV in Architecture 11). 

This system commonality accounts for the virtually identical scores in Environ- 
ment, PMS, and LSC. 

The Human Safety score is dominated by Space Shuttle in all three architectures: 
only 0.5 of the 4.6 and 4.7 crew loss events, in Architectures 11 and 13 respectively, 
and only 0.3 of the 4.6 in Architecture 12, are due to PLS (which flies PLS 20 times 
less). 

The absence of an ACRV in Architecture 11 gives it a slightly higher ACR score than 
12 and 13 (i.e., a lower risk of cost or schedule overruns), but the difference is not 
significant. 

Finding - Architecture 12 has a lower total cost than either Architectures 11 or 13 
($231.9 B versus Architecture 11 at $ 236.7 B and 13 at $ 240.5 B). 

Rationale — Architectures 11 and 13 both have higher costs than 12 because 12 has 
the fewest total flights (and all of the difference is in human flights - the number of 
cargo only flights is identical in each architecture). 
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This is entirely due to the later introduction of PLS in Architecture 12. We noted 
above (in section 3.3.10.5.1) that the introduction of PLS adds many more PLS flights 
than it reduces Space Shuttle flights, because of the large up and down cargo 
requirements of SSF, and PLS's inability to carry cargo. The introduction of PLS 5 
years late in Architecture 12 saves 20 PLS flights at the expense of only 3 Space 
Shuttle flights. 

Finding - Architecture 11 is lower in cost than Architecture 13. 

Rationale -The higher cost of Architecture 13 compared to Architecture 11 is based 
on two factors: 

• Seven additional Space Shuttle flights are required in 13 for ACRV rotation 

• PLS total costs in both architectures are the same; no additional cost is added for 
long-duration PLS capability. 

The second factor will be challenged in the analysis below, and a set of rationalized 
costs for these architectures will be presented. 


3.3.10.5 Analysis of the Consideration 

We noted above that the long-duration PLS of Architectures 11 and 12 was assigned 
identical costs, both non-recurring and recurring, to the short-duration PLS of 
Architecture 13. Architecture 11 and 13 total costs for PLS were identical at $27.4 B; 
Architecture 12 cost was somewhat lower at $23.01 B because fewer PLS flights were 
manifested. 

This is intuitively incorrect. But what cost increment is reasonable for an extended 
duration, personnel vehicle? 

A quick analysis of this question was conducted during the HTS study (the 
conclusion was not available in time to affect the dollar figures used in our 
architecture cost model). 

Data was examined from the Boeing PLS study, from the CLV study, from the EDO 
analyses, and from the preliminary studies of changes necessary for the Russian 
Soyuz to certify it for 2 to 3 years on orbit. Changes were necessary in the following 
systems: 

• Propulsion - The Boeing PLS utilized a "180-day retrofit kit" with isolation and 
pyro valves and a GN 2 purge system, to purge and seal the system for quiescent 
on-orbit stay; a cold-gas system was added for stationkeeping and berthing, etc. 
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• Structure - Changes to external surfaces resistant to degredation by radiation 
and atomic oxygen, and meeting micrometeoroid protection requirements, were 
needed. 

• Power - Fuel cells or batteries were favored for short-duration missions. But 
long duration required either a change in battery technology, or certified 
restartable fuel cells, plus much more efficient cryogenic storage, or solar panels. 

• Thermal control - Recertification of flash evaporators, water boilers, and 
ammonia boilers, or the addition of radiators. Water freezup during passive 
stay was a problem; continuous circulation, addition of heaters, or elimination 
of the water loop were proposed solutions. 

• Life support - Many of the above solutions apply. Cryogenic storage of O 2 and 
N 2 are a particular problem; storage as high pressure gas is feasible, but adds 
weight. 

• Other systems - Using one example from the Orbiter, numerous changes were 
required to the Hydraulics and Water Spray Boiler subsystem, ranging from 
reducing leakage of hydraulic fluid and pressurant gas, to landing gear strut 
heaters; all system components required recertification. 

Long duration requires technology advances, additonal weight, additional 
certification testing, and more extensive overhaul between flights. The estimate 
for the total cost of a system designed to meet these requirements might be 10 
percent higher than that of a short-duration system of otherwise equivalent 
capability. 

Using that estimate, the following changes should be made to the total costs of 
Architectures 11, 12 and 13: 

• To Architecture 11- add $ 2.74 B for long-duration PLS. 

• To Architecture 12 - add $ 2.30 B for long-duration PLS: 

add $ 177 M to correct for the anomalous 
addition of three NLS flights in place of Titan 
flights (see 3.3.10.3). 

• To Architecture 13 - no additions. PLS is short-duration. 

The corrected architecture total costs then become: 

• Architecture 11-$ 236.7 B + 2.74 B = $ 239.4 B 

• Architecture 12 - $ 231.9 B + 177 M 

+ $ 2.30 B = $ 234.4 B 
$ 240.5 B 
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Architecture 13 - These cost revisions force us to restate the last finding in 3.3.10.5.2 
as follows: 

Finding - There is no significant cost difference between Architectures 11 and 13. 

Rationale - The cost increase to ferry the ACRV to and from SSF is offset by the 
increased life cycle cost of a long-duration PLS. 


3.3.10.6 Conclusions 

To the depth of analysis achieved in the HTS, there is no advantage in achieving 
ACRC with a dedicated ACRV, as opposed to a long-duration-capable PLS. The two 
options scored equally well. 

Adding an additional PLS to a transportation architecture which retains the Space 
Shuttle adds significant cost. Thus, delaying such augmentation saves cost by 
avoiding additional human flights. 

More detailed system trade studies are required to determine the true cost of adding 
long-duration loiter capability to a PLS, as opposed to achieving return capability 
with a dedicated ACRV. 
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3.3.11 


Which Booster for Human Flight? Architectures 4, 5. 6, 7. 14 and 17 


3.3.11.1 Description of the Consideration 

A variety of boosters were utilized in the HTS architectures to launch human 
spacecraft. Both existing boosters (Titan II and Titan IV) and proposed new booster 
families (NLS and MLS) were used. This was done in an attempt to determine 
whether a best man-rated booster could be identified, and which of its characteristics 
contributed most to cost-effectiveness, safety, and PMS. 

New concept systems are not included in this consideration. The comparison is 
limited to expendable launch vehicles used to transport cargo to orbit, that can 
additionally be used to transport one or more of the human spacecraft that were 
utilized to test other considerations in the study. 


3.3.11.2 Description of the Systems 

The spacecraft launched on these ELV's included: 

• The PLS, a Boeing /NASA-developed personnel-only spacecraft. It requires a 
40 000 lb class booster for transportation to SSF orbit. 

• The CLV, a scaled-down version of a Space Shuttle-type, winged vehicle 
developed at JSC. It requires an 87 000 lb booster to reach SSF. 

• The RUPC, a Martin concept designed to be launched on the 20 000 lb class 
Titan II booster. 

The boosters used to launch these spacecraft - the key systems to be compared in this 

consideration - were as follows: 

• The NLS-50 was used to launch the PLS in Architecture 4. 

• The MLS-X, a Boeing concept which is a derivative of the NLS-50 optimized for 
human launch, was used to launch the PLS in Architecture 6. 

• The MLS-HL, derived as above but in the 90 000 lb weight class, was used to 
launch the CLV in Architecture 5 and the PLS, together with a cargo carrier in 
Architecture 7. 

• The Titan II was used to launch the RUPC in Architecture 17. 

• A human-rated version of the Titan IV was used to launch the PLS in 
Architecture 14. 
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Analysis of this consideration requires the comparison of system data, not 
architecture data. Therefore, the architectures will not be described here, and 
architecture flight activity and attribute data will not be used. Instead, the pertinent 
characteristics of the boosters will be summarized. Booster cost data will be 
normalized to equivalent launch rates. 


3.3.11.3 Booster Characteristics 

Table 3.3.11.3-1 shows the data for each booster which is relevant to its suitability for 
launching crewed spacecraft. 


TABLE 3.3.11.3-1.- HUMAN-RATED BOOSTER CHARACTERISTICS 


Booster 

Spacecraft & 
Architecture 

PMS 

# Fits per 
Crew Loss 

Cost/Flight at 
350 Tot Fits 

Titan II 

RUPC/17 

.9626 

110 

$52M 

NLS-50 

PLS/4 

.9842 

191 

$91M 

MLS-X 

PLS/6 

.9842 

191 

$93M 

Titan IV 

PLS/14 

.9474 

65 

$172M 

MLS-HL 

CLV/5 

PLS/7 

.9691 


$177M 


Note the following about the data presented in this table: 

• The PMS numbers are for the boosters alone, not for the booster and spacecraft 
combination. These figures are discussed in detail in the Systems Description 
section of this report. 

• The number of flights-per-crew loss event calculations utilize the PMS of the 
booster and spacecraft combination and the abort characteristics of the spacecraft. 
They are not pure booster numbers. They are included because booster PMS 
correlates highly with safety. They are presented as flights-per-loss event to 
make them independent of the number of flights in an architecture. Thus, they 
fairly represent die relative safety of the boosters. 

• The cost-per-flight numbers are for the boosters, not the spacecraft, and are 
without wraps. They are normalized to 350 flights per year, a typical value in 
many architectures. Thus, they represent fair comparisons between the booster 
costs. It should be kept in mind that the payload launch capabilities of these 
boosters vary widely. 

One additional set of cost data is presented below in Table 3.3.11.3-2: typical 

recurring costs for each booster. 
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TABLE 3.3.11.3-2.- BOOSTER RECURRING COSTS 


Booster 

Architecture 

Recurring Costs ($ Millions) 


(Tot# Fits) 

ElSfiifil&ktil 

Production 


Total 

Titan II 

17 (273) 

5,336 

10,037 

712 

16,085 

NLS-50 

4 (310) 

4,819 

36,284 

909 

42,012 

Titan 

IV 

14 (365) 

17,230 

45,484 

3,754 

66,468 

MLS X 
and HL 

6 (577) 
(272X+305HL) 

11,296 


2,319 

108,953 


This table shows the total wrapped recurring costs for each booster in the 
architecture noted. The number of flights of that booster in its Architecture is given; 
these have not been normalized. 

The MLS costs include both the smaller -X and the larger -HL version; costs for each 
were not broken out at the architecture level. 

The purpose of this table is not to present a strict comparison between boosters, but 
to show that the life cycle costs of all are dominated by recurring hardware 
production costs. 


3.3.11.4 Findings 

Finding - The Titan boosters have the lowest PMS and the fewest flights per crew 
loss event. 

Rationale - These are the only existing boosters in the group. They were not 
designed to carry human spacecraft, do not have engine-out capability, and do not 
have a success history as good as that projected for the new systems. 


Finding - Of the new systems studied, the larger booster (MLS-HL) has a lower PMS 
than the smaller ones (MLS-X and NLS-50.) 

Rationale - The MLS-HL requires an upper stage, whose failure probability adds to 
that of the smaller vehicle. The other two have very similar system architectures, 
and thus, identical scores. 


Finding - The cost-per-flight of the three new systems are comparable, given their 
payload launch weight capabilities. 
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Rationale - All use similar technology and configurations. No cost-reducing 
breakthroughs (such as recoverable engines) were utilized. 


Finding - The total costs of all the boosters compared are dominated by recurring 
production costs (see Table 3.3.11.3-2.) 

Rationale - Both the existing and the new boosters studied are completely 
expendable. The costs for new boosters, especially engines, for each flight, far 
exceeds the operational costs of these launch systems. This situation will continue 
unless engine costs can be dramatically reduced, or the engines can be recovered for 
reuse. 


3.3.11.5 Conclusions 

New human-rated boosters can be designed for significant improvements in PMS 
and crew safety. Such an approach appears superior to modifying existing boosters. 

A new booster should be designed for the spacecraft it is to carry. Excess-lift 
capability means higher cost and lower PMS. 

Booster technology development should emphasize the development of systems 
which minimize recurring cost. Recoverable engines are one such possibility. 


3.3-232 


Rev. E 



3.4 NEW WAYS OF DOING BUSINESS (NWODB) 

The final principal task of the study (Task 4) centered around gathering a set of data 
regarding "new ways of doing business", and how those new business approaches 
might reduce cost or increase productivity of space transportation systems. To 
accomplish this task, the HTS NIT distributed a survey to various functional and 
program managers within the aerospace industry. Based upon responses to the 
survey and an assessment of the impact on various stages of systems development 
(e.g., Pre-Phase A through Flight Operations), the areas of greatest potential benefit 
were identified. A description of received responses to the survey is found in 
Appendix F of Volume n. 

After gathering and compiling the survey input, the next step was to focus on 
identifying the level of difficulty in analyzing and implementing the specific 
NWODB suggestions. The intent was to identify any "low-hanging fruit" which 
could be integrated into government operations without much delay. In addition, 
several "attack plans" were formulated for the NWODB suggestions deemed to 
have the greatest potential benefit. 

Most of the information presented below on how the Government could and 
should do business differently is not new and has been identified in other activities. 
However, specific suggestions were offered as to what steps should be taken to assess 
NWODB and how these steps might be implemented with respect to current and 
future transportation systems. In this study, no credit was taken for any cost savings 
associated with NWODB, since it was felt the probability with which NWODB could 
be successfully implemented could not be determined. Moreover, the agency in 
general must be extremely cautious in taking any credit in estimates of future 
program costs that assume the introduction of new business practices that have not 
been demonstrated in NASA. 


3.4.1 NWODB Analysis and Implementation Survey 

Each NIT representative was asked to identify what they considered the top 10 
NWODB options from their perspective and experience. Using these results, the 
NTT evaluated the level of difficulty associated with analysis and implementation of 
each suggested option. 

The following is a short description of the intent of each of the NWODB options 
identified. 

• Minimize the Government Role - Focus the government role to definition of 
the top level requirements of a system or mission, and allow the contractor to do 
the technical job (deciding the best or most cost-effective way to get the job done). 
Government program offices should be small, should shrink in proportion to 
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the contractor work force reductions, and should be focused on verification that 
requirements are being satisfied. 

• Cost Reduction Incentives- Currently contractors are given incentives to meet 
technical and programmatic milestones. Incentives should also be written into 
contracts that encourage cost savings through contractor and employee sharing 
programs. This encourages innovative approaches to getting the job done by 
allowing the contractor to receive greater profits, while reducing the total 
government expense. 

• Provide Program with Adequate Budget - Provide multiyear funding at 
adequate levels to ensure a thorough and efficient effort. Efficiency and 
momentum are lost when a program has to rejustify its existence every year 
during the government budget cycle. Stretching program lengths generally 
increases the total program costs and, therefore, government expenditures. 
Inadequate levels of funding usually result in a reduction in the focus of the test 
program, which results in greater annual costs downstream, increasing the 
overall life cycle costs. 

• Improve Tactical Planning .- A detailed plan with decision points and 
technology insertion junctions would prevent many dead-end programs and 
wasted government and contractor expenditures. 

• Cap Project Growth- Plan development programs to occur over a 3 to 4 year 
period. If this schedule cannot be met, then enabling technologies should be 
pursued and demonstrated in the interim. In addition, projects should be 
terminated if they significantly overrun their projected costs. 

• Design for Operations - It is better to spend extra money up front during 
development, than to suffer with a more complex and expensive ground 
operations system over the life cycle operation of the system. 

• Modify Procurement Process - Streamline and reduce the process of soliciting 
and submitting a proposal and reduce the current proposal boilerplate. In 
addition, include cost risk as an evaluation parameter to reduce the "low- 
bailing" of contractor bids. 

• Modify Procurement Practices - This option covers the government decisions on 
which programs to solicit proposals for and the type of proposals solicited. 
Separate technology development from operational system procurements. Do 
not force fixed price contracts on development programs. Avoid abortive 
procurements. 

• NASA Center Coordination .- Establish clear lines of authority and standardize 
practices. This would provide for a more efficient and focused dvil servant work 
effort. 
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• Communication Enhancements - Reduce the number of contract data 
requirements, and the scope and number of formal reviews through electronic 
communication, on-site visits, or co-location of government and contractor 
teams. 

• Improve Management and Engineering Techniques - Utilize concurrent/ systems 
engineering philosophies early in programs, utilize Total Quality Management/ 
QFD methodologies throughout the program, and operate using a team 
philosophy between the government and the contractor. 

• Streamline Contracted Research and Development Change Mechanism - Reduce 
the number of people and the amount of time required to make a contract 
change. 

• Focus Program Requirements - Program requirements should focus on what the 
mission to be accomplished is and not on how to get the job done. These should 
be specified up front and not modified unless significant cost savings can result. 


3.4.2 Survey Results 

Once all the inputs were gathered, the team met again to reevaluate the potential 
benefit, analysis difficulty, and implementation difficulty of the above options. The 
following three criteria were used to determine how well each suggested option 
could be implemented. The results of this assessment are shown in Table 3.4.2. 

Potential Benefit 


• High - Enables new mission and new system starts in the near term. 

• Medium - Results in moderate cost savings to current programs that can be 
reinvested (in technologies, personnel, or equipment) over time to make future 
programs and systems more cost effective. 

• Low - No significant cost savings to current or future programs and systems. 

Availability and Access to Data (Analysis Difficulty) 

• High - Data readily available with some research. 

• Medium - Would require a dedicated NWODB study to quantify the potential 
benefit. 

• Low - Extremely difficult to find data, probably never be able to quantify. 
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Probability of Implementation (Implementation Difficulty) 

• High - Program manager level implementation decision. 

• Medium - Within NASA but at higher levels than program manager. 

• Low - Outside of NASA, e.g.. Act of Congress. 


TABLE 3.4.2.- ASSESSMENT OF NWODB OPTIONS 


New Ways of Doing 
Business Options 

Potential 

Benefit 

Availability & 
Access to Data 

Probability Of 
Implementation 

1 Minimize the Government Role 

H 

M 

M 

2 CostReduction Incentives 

H 

M 

M 

3 Provide Prog. w/Adequate Budget 

H 

H 

L 

4 Improve Tactical Planning 

M 

M 

M 

5 CapProjectGrowth 

M 

H 

L 

6 Design for Operations 

H 

M 

M 

7 Modify Porcurement Process 

L 

M 

L 

8 Modify Procurement Practices 

M 

M 

L 

9 NAS A Center Coordination 

M 

L 

M 

10 Communication Enhancements 

L 

H 

H 

11 Improve Mgt/Eng. Techniques 

M 

L 

H 

12 Streamline CRAD Change Mech. 

L 

M 

M 

13 Focus Program Requirements 

H 

M 

M 


3.4.3 New Ways of Doing Business (NWODB) Attack Plans 

The following outlines describe potential attack plans to address the top five areas 
identified as having the greatest potential benefit. 

General Considerations 

• Access to data.- To truly understand the impact of new business approaches, it is 
essential to have quantifiable data such that architectures can be rerun with the 
projected cost savings. However, 

some things may be difficult or impossible to measure, in which case one 
would have to drop back to a qualitative measurement or discussion. 
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- some analyses may require more effort than can be reasonably expected, given 
the finite study schedule and resources. In this case, one would identify the 
potential benefit and recommend further analyses in a follow-on effort by the 
appropriate agent (e.g., NASA, HTS NIT, OMB, etc.). 

- some useful data could be lost due to proprietary considerations. These will 
be addressed on a case-by-case basis. 


3.4.3. 1 NWODB Area #1 

Limit government role to oversight and verification that requirements are satisfied 
and allow contractor to perform assigned role. Reductions in government oversight 
should reduce the contractor costs as well as government costs to manage the 
contractor (included in the wraps). 

Several case studies were recommended for examination in this attack plan. They 
included Atlas, Delta Star, and the EDO. The General Dynamics (GDSS) Atlas 
launch vehicle program was selected to compare and contrast the impacts of 
government oversight on launch costs and schedule, versus similar commercial 
launches. Although the data research for this task was not completed during the 
study, a good qualitative assessment was made. 

Table 3.4.3.1 shows the level of government oversight categories that GDSS products 
can be organized into, which ranges from full military to commercial levels of 
oversight. In the interest of bounding the problem and reducing the amount of 
research, it may be appropriate to look at an MLV II versus a commercial mission 
like the payload BS-3H (highlighted in the table). To quantify the differences 
between these two extremes, several discriminators were identified for which data 
would be gathered. These discriminators are described below 
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TABLE 3.4.3. 1.- IMPACTS OF VARYING LEVELS OF OVERSIGHT ON SPACE 

LAUNCH ACTIVITIES. 




Full Military 

Partial Military 

Commercial 

Government 

Rigorous 

Commercial 

Commercial 

Designation 
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(9 others) 
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(AC 104) 

EUTELSAT 
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GALAXY 
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ORION 
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MSAT 
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oc 
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• Number of Oversight Organizations - As the number of organizations involved 
in the oversight of a launch increase, the costs incurred by the supplier must also 
increase. Commercial missions often have few (sometimes none) additional 
organizations interfacing with the supplier, other than the customer. This is a 
relatively easy discriminator to measure, but harder to translate into cost 
impacts. 

• Costs - This is obvious; the greater the oversight, the higher the cost for a 
product or service. Again, it is an easy number to find, but would be company 
proprietary. However, it can likely be documented in a relative sense (as a ratio 
between government and commercial). 

• Action Items.- Generally, the more oversight, the more work will be generated 
for which the supplier must respond. Action items are tracked, but are difficult 
to normalize (i.e., which ones are the contribution from the added oversight 
versus other factors). For example, interfacing with a foreign customer may 
result in actions related to communication items because of the distance and 
time differential. 


3.4-6 


Rev. E 



























• Engineering Changes - This may not be a good discriminator for quantifying the 
impacts of oversight. It is more likely a reflection of the technical challenge 
associated with the job and would, therefore, have to be carefully normalized. 

• Integration Time - This may also not be a good discriminator because so many 
other factors enter into the equation, such as commonality with a previous 
launch, payload availability, launch vehicle modifications, etc. Again, a careful 
normalization would be required to determine the impacts of levels of oversight. 

• Number and Type of Procedures.- This may not be a good discriminator for 
Atlas because the procedures are fairly consistent across the spectrum. 

• Amount of Documentation - This item is fairly easy to measure and translate 
into costs. 

• Level of Empowerment - This item is hard to quantify and translate into costs 
but may be interesting to see and compare. However, one could show a chain-of- 
authority diagram with key decision makers identified. 

Suggested Attack Plan 

1. Identify programs that have limited government oversight (e.g., comparison of 
commercial vs. government ELV launches). 

2. Identify the benefits derived from limited government oversight. 

3. Determine how the level of oversight was established or negotiated. 

4. Develop justifications to support implementation of reduced oversight (e.g., 
architecture costs with or without limited oversight). 

5. Develop methods for implementation of reduced government oversight to 
current and future programs. 

6. Identify candidate programs for implementation of reductions in government 
oversight. 

7. Present results and recommendations to NASA and Industry representatives. 
Seek feedback, consensus, and commitment to change. 

8. Track implementation of reduced government oversight on programs and 
document process (i.e., lessons-learned, innovative approaches, road blocks, 
etc.). 
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3A.3.2 NWODB Area #2 


Place more emphasis on project accomplishment rather than reporting , 
documentation, justification, etc. Reporting allows the government to ensure that 
progress is being made towards the desired goal, and allows the results to be 
preserved for future reference and to inform a wider distribution of interested 
parties. The focus here must be to obtain an optimal mix to increase the efficiency of 
taxpayer contributions. 

Su ggested Attack Plan 

1. Identify the standard reporting and documentation requirements for various 
programs. 

2. Assess the need for each data product in terms of government decision making 
and program direction maintenance. 

3. Identify and analyze other ways to satisfy government needs in lieu of excessive 
reporting or documentation (e.g., co-location of government and 

contractor program teams, electronic network communications, etc.) 

4. Recommend reporting and documentation alternatives available to govern- 
ment program managers that sufficiently cover needs, without hampering 
productivity. 


3.4.3.3 NWODB Area #3 

Provide multiyear funding. This would be extremely difficult to accomplish. It will 

be much easier to analyze the problem than to define a solution that does not 

require divine intervention. 

Suggested Attack Plan 

1. Select and examine several programs that have been severely impacted by the 
lack of multi-year funding (e.g., SSF or NLS). 

2. Assess the impacts quantitatively and qualitatively. 

3. Identify changes in government procurement and contracting policies, 
procedures, regulations, and/or laws necessary for multiyear funding 
commitments. If no changes are required, understand how it is authorized. 

4. Recommend and justify the characteristics of programs that should be 
authorized for multiyear funding. 
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5. Identify programmatic approaches that would reduce the magnitude of the 
impacts (e.g., program funding risk assessments and mitigation plans). 


3.4.3.4 NWODB Area #4 

Institute a rigorous systems engineering approach to definition and development of 
projects. Application of a systems engineering approach to any program will entail 
philosophical and operational modifications. The systems engineering approach 
should be implemented from the very beginning, starting with initial requirements 
generation and continuing throughout all phases and levels of a program. This 
approach should be utilized by both contractor and government to assure successful 
implementation. 

Suggested Attack Plan 

1. Identify systems and concurrent engineering references. 

2. Determine the benefits for application of systems engineering methods to 
programs of various sizes and focus. 

3. Recommend a functional breakdown for a concurrent engineering team. 


3.4.4 Conclusions 

• The HTS NIT consensus (plus others in the aerospace industry) is that there may 
be great potential to free up money for new missions and new systems through 
implementation of NWODB. 

• Based upon limited analysis, it is apparent that the availability and access to data 
prohibits a full understanding of new business impacts. A separate study or 
group of studies is required to quantify the benefits of NWODB options. 

• Many of the NWODB options are under the direct control of NASA, although 
they need the support and authority of upper level NASA management for 
implementation. 

• There is a need to involve the upper management of NASA and industry to 
assure the access to data, the commitment to change, and the demonstration of 
NWODB viability through implementation into existing programs. Until such 
time as new business practices can be demonstrated within NASA, the agency 
should be extremely cautious in development and use of future project cost 
estimates including NWODB. 
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3.5 SENSITIVITY STUDIES 


At the completion of the main body of work for the HTS study, there were a series of 
questions, sensitivities, or trades which the study team felt were important to 
address. These included the sensitivity of the results to differing mission needs, 
additional refinements of the methodology used to calculate attributes, and 
additional definition of the systems and architectures of the study. This additional 
work is described in the following paragraphs. 


3.5.1 Needs Model Sensitivity 

3.5.1. 1 SSF Logistics Return Requirement Reduction 
Introduction 


This section documents the impact of reducing SSF logistics return mass on the 
study architectures and their attribute values. Among the results reported are the 
flight rates and the three major contributing attributes of the architecture scores; 
Human Safety, Funding Profile, and Probability of Mission Success. Since together 
they make up 75 percent of the architecture scores, only these attributes will be 
described in the following architecture results. 

For the HTS study the return mass is made up of the ISF, Satellite Servicing, Sortie 
Science and SSF payloads. Most of this mass is included in the SSF program in the 
form of scientific payloads and pressurized and unpressurized logistics payloads. To 
assess the effect of reduced SSF return requirements on the architectures, a 
sensitivity analysis was performed in which portions of the SSF logistics return 
mass were reduced. In addition, all ISF and Sortie Science missions were eliminated 
(both delivery and return). 

Based on this analysis, several generalized observations were made. Emphasis was 
placed on understanding both architecture-dependent and architecture-independent 
impacts. 

An analysis of the SSF mass return requirements showed that, on average, SSF 
scientific payloads make up only 14 percent of the return mass (Figure 3.5.1. 1-1). 
Eighty-six percent of the return mass is attributed to the logistics payloads; 30 percent 
unpressurized and 56 percent pressurized. In performing the sensitivities analysis, 
three possibilities were examined: 

• Return all mass required in the HTS Mission Model (100 percent return 
required). 
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• Return only 50 percent of the pressurized and unpressurized logistics payloads 
and all SSF scientific payloads (57 percent SSF return required), and 

• Return only the scientific payloads (14 percent SSF return required). 

In both the 57 percent and 14 percent cases, both the ISF and Science Sortie mission 
requirements were excluded as mentioned above. 



AVERAGE UNPRESSURIZED SSF LOGISTICS: 30% 



00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 

CALENDAR YEAR 


Figure 3.5.1. 1-1- SSF return mass distribution. 


Ground Rules and Guidelines 

The sensitivity analysis conformed strictly to the HTS manifesting and costing 
ground rules and assumptions, except for the missions (ISF, Sortie Science and SSF 
logistics) that were modified, rearranged, or deleted. 

Although return mass was eliminated, the corresponding delivered mass was still 
required in the analysis. By doing this, it was assumed that the basic mission 
requirements and objectives (with specific mass delivered to orbit at specific time) 
must still be satisfied. Also assessed was the possibility of disposing of the logistics 
return mass, together with its consequences on the architecture, but not the effect of 
additional costs or other requirements on the SSF program itself. 


Summary of Results 

This section documents the results and observations obtained from the return 
reduction sensitivity analyses. In most cases, only the baseline manifesting ground 
rules were used, with the different mass return level being the only change. Some 
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other sensitivities, such as maximizing manifesting efficiency or substituting other 
appropriate vehicles in the architecture, were performed. 

The following sections discuss the flight rate impacts followed by architecture 
impacts of reducing SSF logistics return mass. 

a. Architecture 1 - "If" C .- For this case, reducing the SSF return mass does not 
necessarily reduce Space Shuttle flights, since the Space Shuttle must deliver 
payloads to the SSF regardless of how much return mass is eliminated. The 
cause of the reduced number of flights shown in Figure 3.5. 1.1 -2 is the 
elimination of ISF and Sortie Science missions in the 57 percent and 14 percent 
cases. From the architecture standpoint, this saved one crew loss event, cut the 
total cost by more than $5 billion, and reduced the number of reflights by more 
than five flights (Table 3.5.1. 1-1). 


Architecture l-"If" C 



100 % 57 % 14 % 


SSF Mass Return Percentage 


Figure 3.5.1. 1-2- Architecture 1 - "If" C reduced return requirement 
sensitivity flight rates. 
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TABLE 3.5.1. 1-1- ARCHITECTURE 1 - "IF" C REDUCED RETURN SENSITIVITY 

ATTRIBUTE RESULTS 



Note: The 57% and 14% cases do not include ISF and Sortie Science Missions. 


b. Architecture 1A - "If" C - This architecture has two systems flying SSF missions: 
the Space Shuttle and the Titan IV/CTF. Reducing SSF return mass from 
100 percent to 57 percent helps decrease the number of Space Shuttle flights, 
while increasing CTF flights, as shown in Figure 3.5.1. 1-3. The ISF and Sortie 
Science missions deleted in the 57 percent case further contributes to Space 
Shuttle flight reduction. The Space Shuttle must continue at least four crew 
rotation flights per year to the SSF in all cases, including the 14 percent case, 
therefore its usage does not show any significant reduction. On the other hand, 
because more SSF logistics payloads which can be off-loaded from Space Shuttle 
exist in the 14 percent case, the CTF flight rate is increased. 


Architecture 1 A-"If ’ C 



100 % 57 % 14 % 

SSF Mass Return Percentage 

Figure 3.5.1.1-3. Architecture 1A - "If" C reduced return requirement sensitivity 
flight rates. 
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As a sensitivity to Architecture 1A, some of the mission capture groundrules and 
assumptions to maximize payload manifesting on the Space Shuttle before a CTF 
is utilized were modified. For this case, the Space Shuttle flight rates are 
maintained at the levels of the previous case. In addition, the manifest on the 
Space Shuttle flights using SSF payloads with no return mass requirements were 
optimized. The net effect is to increase Space Shuttle usage, with the few 
remaining missions having no return mass able to go on the CTF. This results 
in a somewhat lower number of CTF flights in both the 57 percent and 14 percent 
cases (Figure 3.5.1. 1-4) as compared to Architecture 1A - "If" C. 


Architecture lA-"If' C 
Maximum Shuttle Efficiency 



100 % 57 % 14 % 


SSF Mass Return Percentage 

Figure 3.5.1. 1-4 - Architecture 1A (maximum efficiency) - "If' C reduced return 
requirement sensitivity flight rates. 

Attribute values of Architecture 1A (with maximum manifesting efficiency) are 
shown in Table 3.5.1.1-2. Because more one-way payloads fly on the CTF in the 
14 percent case than the 57 percent, the total architecture cost and number of 
reflights are slightly higher. However, the improvement in safety may be worth 
the extra $1.7B to eliminate one crew loss event. 
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TABLE 3.5. 1.1-2.- ARCHITECTURE 1A (MAXIMUM EFFICIENCY) - "IF" C 
REDUCED RETURN SENSITIVITY ATTRIBUTE RESULTS 


SSF 

Return 

Case 

Flight Rate 

Attributes 

Space RPC CTF/CTV CRV/LRV 
Shuttle 

Safety Peak 

(Crew Total Cost Funding 
Loss 092 $B) 092 $B) 

Events) 

100% 

57% 

14% 

292 0 78 0 

228 0 54 0 

220 0 74 0 

7 106.4 5.40 

6 98.1 5.26 

5 99.8 5.31 


Note: The 57 percent and 14 percent cases do not include ISF and Sortie Science 
Missions. 


c. Architecture 3 - "If" C .- The result for this architecture is almost identical to that 
of Architecture 1A. Here the Titan IV/CTF is replaced by the NLS-HL/CTV, 
which has more than twice the Titan IV/CTF performance (101 000 lbs vs. 

40 000 lbs). Therefore, the Space Shuttle flight rate trend is similar, while the 
NLS-HL/CTV flights are less than half of the Titan/IV/CTF in the previous case 
(Figure 3.5.1. 1-5). 
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100% 57% 14% 
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Figure 3.5.1. 1-5 - Architecture 3 - "If" C reduced return requirement 
sensitivity flight rates. 
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Similar to Architecture lA-Maximum Efficiency, Architecture 3 with maximum 
efficiency was also analyzed. In this case, the Space Shuttle flight rates are roughly 
the same. In addition, the manifest on the Space Shuttle flights with SSF payloads 
having no return mass were optimized. The net effect is to maximize Space Shuttle 
payload usage with only the few remaining missions having no return mass flying 
on the CTV. This results in a somewhat lower CTV flight rate in both the 57 percent 
and 14 percent cases (Figure 3.5. 1.1-6) as compared to Architecture 3-"If" C. 


Architecture 3-"If ' C 


1000 y 

800-l- 


Maximum Efficiency 
• Sortie Science & ISF Return Mass 
Also Deleted 


(A 



□ NLS-HL/CTV 
B Space Shuttle 


100% 57% 14% 


SSF Mass Return Percentage 


Figure 3.5.1. 1-6 - Architecture 3 (maximum efficiency) - "If’ C reduced return 
requirement sensitivity flight rates. 


Similarly, for the architecture attributes, there is a drop in the total cost and number 
of reflights when reducing to the 57 percent mass return level. However, again this 
slightly increases in the 14 percent case due to additional NLS-HL/ CTV flights, as 
shown in Table 3.5.1. 1-3. 
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TABLE 3.5.1. 1-3- ARCHITECTURE 3 (MAXIMUM EFFICIENCY) - "IF" C REDUCED 
RETURN SENSITIVITY ATTRIBUTE RESULTS 



Note: The 57 percent and 14 percent cases do not include ISF and Sortie Science 
Missions. 


d. Architec ture 5 - "If 1 C .- In Architecture 5, the Space Shuttle is phased out by a 
combination of MLS-HL/CLV, MLS-HL/CRV, and MLS-HL/CTF. The CLV can 
carry a crew of ten and 15 000 lbs to the SSF. 

Figure 3.5. 1.1 -7 shows the total flight results. As less mass needs to be returned, 
the untended CRV is less likely to be required, until there is no need for it in the 
14 percent case, as shown in the figure. On the other hand, as more one-way 
delivery mass is available, the CTF usage increases. The CLV flights must be 
maintained to provide the crew rotation function. 


Architecture 5-"If" C 



100 % 57 % 14 % 


SSF Mass Return Percentage 

Figure 3.5.1. 1-7 - Architecture 5 - "If" C reduced return requirement 
sensitivity flight rates. 
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An attempt was made to maximize payload manifesting, as shown in 
Figure 3.5.1. 1-8. Because payload manifesting was maximized on already existing 
CLV flights for crew rotation and CRV flights, there is no need for the CTF in the 
57 percent case. Conversely, in the 14 percent case, only the CLV and the CTF is 
required payload delivery. This result is similar to the result above, with a lower 
number of flights due to greater manifesting efficiency. Table 3.5.1. 1-4 
summarizes the major architecture attributes. 


Architecture 5- "If" C 
1000 y Maximum Efficiency 

• Sortie Science & ISF Return Mass 



100 % 57 % 14 % 

SSF Mass Return Percentage 

Figure 3.5. 1.1 -8.- Architecture 5 (maximum efficiency) - "If" C reduced return 
requirement sensitivity flight rates. 


TABLE 3.5.1. 1-4.- ARCHITECTURE 5 (MAXIMUM EFFICIENCY) - "IF" C 
REDUCED RETURN SENSITIVITY ATTRIBUTE RESULTS 



Note: The 57 percent and 14 percent cases do not include ISF and Sortie Science 
Missions. 
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e. Architecture 6 - "If C - In Architecture 6, the Space Shuttle is phased out by a 
combination of MLS-X/PLS, MLS-HL/CRV, and MLS-X/CTF systems. All 
payload return is provided on the MLS-HL/CRV. The flight rate results are 
shown in Figure 3.5.1. 1-9. 


Architecture 6-"If” C 



100 % 57 % 14 % 


SSF Mass Return Percentage 


Figure 3.5.1. 1-9- Architecture 6 - "If" C reduced return requirement 
sensitivity flight rates. 


Because all one-way payloads, including SSF logistics, are launched on the MLS- 
X/CTF, which has less capacity, the total number of flights increased in the 
14 percent case. The MLS-HL/CRV still is used for returnable payloads, 
including SSF scientific. Satellite Servicing and some Base payloads. 

The attribute values for this architecture indicate clearly the impact of reducing 
the return mass requirements (Table 3.5. 1.1-5). As the return mass is reduced, 
and as the Space Shuttle is phased out, the PLS must continue flying to provide 
crew rotation missions. In addition, both the CTF and CRV flight rates must 
increase to carry all the payloads. This also increases the MLS-X and MLS-HL 
flights (since they serve as booster stages for both CTF and CRV), thereby 
increasing the total cost. Similar results were obtained for Architecture 7 as well. 
In this case, both a CRV and an LRV (launched on a larger booster concurrently 
with the PLS) are used to replace the Space Shuttle. 
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TABLE 3.5. 1.1-5 - ARCHITECTURE 6 - "IF" C REDUCED RETURN SENSITIVITY 

ATTRIBUTE RESULTS 



Flight Rate 

Attributes | 

SSF 





Safety 


Peak 

Return 

Space 




(Crew Loss 

Total Cost 

Funding 

Case 

Shuttle 

RPC 

CTF/CTV 

CRV/LRV 

Events) 

(’92 $B) 

('92 $B) 

100% 

102 

186 

0 

230 

4 

147.3 

11.3 

57% 

87 

148 

96 

146 

3 

144.5 

11.6 

14% 

96 

148 

137 

142 

3 

149.1 

11.6 


Note: The 57 percent and 14 percent cases do not include ISF and Sortie Science 
Missions. 

Generalized Findings 

The following discussion is based mainly on examination of the 57 percent and 
14 percent reduction case results. Because the 100 percent case includes the ISF and 
Sortie Science missions, it is not directly comparable to the other two cases. Future 
analyses should provide consistent requirements across all cases for a more accurate 
comparison. 

In all cases, the CTV (or CTF) capability made sense only for delivery-only type 
missions, i.e., when their return mass requirement is reduced. This is obvious since 
that is what it is designed to do. However, merely reducing return mass does not 
necessarily improve architecture attributes. In some architectures, the 14 percent 
case is better than the 57 percent case (Architecture 1); in others it is not 
(Architectures 1A, 3, and 6). The main issue involves knowing how much to 
reduce SSF logistics mass required and to balance its usage, given development and 
per-flight costs. 

On the average, elimination of either half (57 percent case) or nearly all (14 percent 
case) of SSF logistics return requirements gives similar flight results for the Space 
Shuttle. Both scenarios indicate savings of two SSF logistics flights per year and one 
non-SSF logistics flight per year. 

With the elimination of SSF logistics return requirements, the combination of the 
CTF and CLV systems is adequate to replace the Space Shuttle. In this case, there is 
no need for a separate CRV. 

By reducing the requirement for return cargo, as in the 14 percent case, the need for 
a separate CRV is eliminated in Architecture 5, because of the cargo return capability 
of the CLV. However, in Architecture 6, where the PLS has no cargo capability, a 
separate CRV is still required. 
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3.5.1. 2 Flight Rate Smoothing Analysis 

A principal study groundrule was that manifesting of each payload would occur in 
the year identified by the mission model. However, it might be more efficient to 
allow payloads to float into adjoining years if a facility or element limitation 
(provided launch window constraints are properly met) was encountered. 

To understand this impact, the cost savings that could be achieved, over the baseline 
case, by allowing an architecture to fully spread its flight rate requirements across the 
study time frame has been examined. This would level facility, equipment, and 
reusable element usage. This can be compared to the average flight rate for a system 
with the flight-rate-delineated trigger points for each facility, equipment, and 
reusable element (i.e., when new purchases are required) that are accounted for in 
the cost analysis. The savings are the costs for the triggers that were avoided by 
flight rate smoothing when compared with the peak annual flight rate of the given 
architecture. Figure 3.5. 1.2-1 depicts this analysis process. 


1 

a 

2 


Peak Flight Rate 

Average Flight Rate 



Cost Savings 
from Flight Rate 


Smoothing 






Smoothed 

Costs 

x 


Year 


Trigger Points 



S 2 1 

etf 55 ^ 


Figure 3.5.1. 2-1.- Flight rate smoothing sensitivity methodology. 


Architectures 1, 2, 5, and 6 were selected for analysis in "If’ Scenario C only. Tables 
3.5.1. 2-1 through 3.5. 1.2-4 present the results of this analysis, respectively. The 
results range from a cost savings of $2.2B to $3.0B for architectures whose total costs 
range from $131B to $234B. The maximum savings could be 2.3 percent (3.0/131) or 
less. Therefore, flight rate smoothing alone was not considered to have a significant 
impact upon the total architecture cost. Research into the year in which the 
triggered costs were incurred showed that they did not coincide with each other or 
with the PYF in the funding profile curve. Therefore, flight rate smoothing alone 
was not considered to have a significant impact on the attribute. Thus, this 
manifesting groundrule was found to have a non-deleterious impact on the study 
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results. However, if a budget-wedge analysis were performed and used as a relative 
measure of goodness, the smoothed flight rate savings could have a more signifi- 
cant impact. This was not done on this study. 


TABLE 3. 5. 1.2-1.- ARCHITECTURE 1 - "IF" C FLIGHT RATE SMOOTHING 


Arch 

System 

Peak/ 

Site 

Trigger 


Fits/Site 

Ave 

Flt/Yr 

$ Savings 

1C 

Space Shuttle- 
ETR 

12 

Orbiter @11 (1) 

29 

292 

10.1 

1637 

1C 

Delta-ETR 

7 


23 

127 

5.5 


1C 

Delt-WTR 

3 


23 

34 

1.5 


1C 

Atlas-ETR 

3 


23 

69 

3.0 


1C 

Titan IV ETR 

8 


23 

135 

5.9 


1C 

Titan IV WTR 

4 

SLC @ 4 (1) 

23 

68 

3.0 

596 

1C 

Titan 1I-WTR 

2 


23 

31 










2233 


TABLE 3.5.1.2-2- ARCHITECTURE 2 - "IF' C FLIGHT RATE SMOOTHING 


Arch 

System 

Peak 

/Site 

Trigger 

Ops Yrs 

Fits/Site 

Ave 

Flt/Yr 

$ Savings 

2C 

Space Shuttle- 
ETR 

12 

Orbiter @ 11 (1) 

12 

97 

8.1 

1637 

2C 

Space Shuttle 
Ev-ETR 

8 


21 

147 

7.0 


2C 

RCV-ETR 

5 


21 

83 

4.0 

0 

2C 

All Space 
Shuttle 

13 


29 

327 

11.3 


2C 

Delta-ETR 

7 


23 

127 

5.5 


2C 

Delta-WTR 

3 


23 

34 

1.5 


2C 

Atlas-ETR 

3 


6 

11 

1.8 


2C 

Atlas Ev. -ETR 

3 


21 

58 

2.8 


2C 

Titan IV-ETR 

8 


5 

20 

4.0 


2C 

TIV Evol-ETR 

7 


21 

115 

5.5 


2C 

Titan IV-WTR 

4 

SLC @ 4 (f) 

5 

9 

1.8 

596 

2C 

TIV Evol-WTR 

4 


21 

59 

2.8 


2C 

Titan II-WTR 

2 


23 

31 










2233 
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TABLE 3.5.1.2-3 - ARCHITECTURE 5 - "IF" C FLIGHT RATE SMOOTHING 


Arch 

System 

Peak/Site 

Trigger 

Ops Yrs 

Fits/Site 

Ave 

Flt/Yr 

$ Savings 

5C 

Space 

Shuttle-ETR 

12 

Orbiter @ 
11 (1) 

12 

108 

9.0 

1637 

5C 

CLV-ETR 

13 

CLV @ 12.5 
(1) 

21 

216 

10.3 

738 

5C 

CRV-ETR 

7 

CRV @5 
(1) 

21 

89 

4.2 

68 

5C 

MLS-ETR 

24 


21 

417 

19.9 


5C 

MLS-WTR 

3 


21 

49 

2.3 


5C 

Delta-ETR 

7 


23 

127 

5.5 


5C 

Delta-WTR 

3 


23 

34 

1.5 


5C 

Atlas-ETR 

3 


23 

69 

3.0 


5C 

Titan IV-ETR 

8 


5 

23 

4.6 


5C 

Titan IV- 
WTR 

4 

SLC @ 4 (1) 

5 

9 

1.8 

596 

5C 

Titan II-WTR 

2 


23 

31 

1.3 









3039 


TABLE 3.5.1. 2-4.- ARCHITECTURE 6 - "IF" C FLIGHT RATE SMOOTHING 


Arch 

System 

Peak/Site 

Trigger 

Ops Yrs 

Fits /Site 

Ave 

Flt/Yr 

$ Savings 

6C 

Space Shuttle- 
ETR 

12 

Orbiter 
@ 11 (1) 

12 

102 

8.5 

1637 

6C 

PLS-ETR 

16 


21 

186 

8.9 


6C 

CRV-ETR 

13 


21 

230 

11.0 


6C 

MLS-ETR 

30 

CIF @ 
25.2 (1) 

21 

528 

25.1 

93 

6C 

MLS-WTR 

3 


21 

49 

2.3 


6C 

Delta-ETR 

7 


23 

127 

5.5 


6C 

Delta-WTR 

3 


23 

34 

1.5 


6C 

Atlas-ETR 

3 


23 

69 

3.0 


6C 

Titan IV-ETR 

8 


5 

23 

4.6 


6C 

Titan IV-WTR 

4 

SLC @4 
(1) 

5 

9 

1.8 

596 

6C 

Titan II-WTR 

2 


23 

31 

1.3 








Savings= 

2326 
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3.5.1. 3 Comparison of HTS Needs Model With Current FY92 
Civil Needs Data Base (CNDB) 

The condusions of the HTS study are based on data derived and modified from the 
1990 CNDB. A question arose over whether or not the condusions of this study 
would be changed if the data from the 1992 CNDB was used in place of the data from 
the 1990 version. A sensitivity study was performed to address this question by 
comparing the transportation requirements identified for SSF in the HTS modified 
1990 CNDB and the unmodified 1992 CNDB. 

As noted previously, the data from the 1990 CNDB has been adjusted and modified 
for use in the HTS study and, as such, includes some extrapolations and data 
smoothing. These modifications have been discussed in other parts of this report. 

In the following discussion, all references to the 1990 CNDB refer to the HTS- 
modified version. 


This study compared the transportation requirements, for SSF as documented in the 
1990 and 1992 CNDB's. These transportation requirements were identified for the 
Base and Expansion phases of the project. The Base phase covers all of the SSF 
activities up to and including PMC and extending through four crew operations. 

The Expansion phase includes all of those activities needed to establish and 
maintain eight crew operations at SSF. Delivered and retrieved cargo masses were 
tabulated on both an annual basis and a cumulative basis for the Base and 
Expansion phases, as well as for their combined total. This analysis was performed 
by extracting all of the SSF payloads from the respective editions of the CNDB, and 
then using Excel spreadsheets to manipulate, sort, and plot the data. 

Total Annual Delivered Masses 

Figure 3.5.1. 3-1 compares the total annual delivered mass requirements for SSF 
(PMC phase). Data is shown for the 1990 and 1992 CNDB's. 
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Total Annual Delivered Mass for 1990 & 1992 CNDB - BASE 



Figure 3.5.1 .3-1- Total annual delivery mass requirements for SSF (PMC Phase). 


There is reasonably good correlation between the two models out through the 2010 
time frame, at which time the data from the 1992 CNDB shows a significant 
reduction relative to the data from the 1990 CNDB. This can be attributed to 
modifications that were performed to the 1990 CNDB to include additional 
requirements for logistic support, which were beyond the planning horizon of those 
providing the payloads inputs. (It was assumed that a steady-state operation of the 
PMC station would not have such a drop-off in the 2010 time frame.) Although 
differences exist in these two models prior to 2010, these differences are basically 
fluctuations around the values from the 1990 CNDB that can be attributed to 
differences in when specific payloads are manifested and to the evolution of the 
mass estimates for specific payloads. 

Total Annual Return Masses 

Figure 3.5.1.3-2 compares the total annual return mass requirements for SSF (PMC 
phase) for the 1990 and 1992 CNDB's. 
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Figure 3.5.1.3-2- Total annual return mass requirements for SSF (PMC Phase). 


Again, this chart shows reasonably good correlation between the 1990 and 1992 
CNDB results. The trend lines are similar although there are some significant 
variations from year to year. However, note that the differences generally average 
out, i.e., the two curves fluctuate around each other. The only time this is not true 
is in the post-2010 time frame and those differences are thought to be attributable to 
the smoothing of the 1990 CNDB data described above. 


Cumulative Total Delivery Mass 

Figure 3.5. 1.3-3 compares the cumulative delivered mass requirements. As one 
would expect, this curve shows considerably less scatter than the annual delivered 
mass charts previously shown. As with the previous charts, there is a good 
correlation between the 1992 and 1990 CNDB results, although the cumulative mass 
values from the 1992 CNDB are slightly lower than those from the 1990 CNDB. The 
two curves show their most significant divergence in the post-2010 time frame. It is 
significant to note the similarity of the slopes of the two curves in the pre-2010 time 
frame. The differences between these two curves can largely be explained by 
postulating a time shift of roughly 12 to 18 months between the two traffic models. 
This suggests that the 1992 CNDB can be viewed as a slightly delayed version of the 
1990 CNDB. This is consistent with the schedule changes that have occurred in the 
SSF program subsequent to the development of the 1990 CNDB. Thus, the 1992 
CNDB does not represent a change in the mass delivery requirements for SSF, 
instead it is just a slight adjustment to the schedule for the delivery of that mass. 
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Figure 3.5.1. 3-3 - Cumulative delivery mass to SSF (PMC Phase). 


Cumulative Total Return Mass 

Figure 3.5.1. 3-4 compares the cumulative retrieved mass requirements. Notice the 
very high degree of correlation between the two curves. There are only slight 
differences between these two curves until the 2010 time frame, and after that time 
the differences remain small. 
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Figure 3.5.1.3-4.- Cumulative return mass to SSF (PMC Phase). 


Maximum Annual Mass Transport Requirements 

Table 3.5.1. 3-1 compares the maximum delivered and return masses for the 1990 and 
1992 CNDB's for the various SSF operational phases. The purpose of this is to 
quantify when the peak transport requirements occur, and to identify their 
magnitude. 


TABLE 3.5.1. 3-1.- MAXIMUM ANNUAL MASS TRANSPORT 
REQUIREMENTS FOR SSF 


CNDB Model 

Max Annual Mass (lbs) 

Year 

Delivered Pavloads 



1990 

291,941 

2000 

1992 

262,847 

2002 

Return Pavloads 



1990 

178,700 

1 

1992 

213,836 














Notice that the peak delivered payload transportation requirement for the 1992 
CNDB occurs roughly 2 years after the peak for the 1990 CNDB. This is consistent 
with the notion that the dominant difference between the two CNDB's is that the 
1992 CNDB is time-shifted relative to the 1990 CNDB, due to stretch outs in the SSF 
program that occurred after the 1990 CNDB was formulated. Although there are 
differences between the maximum annual delivered masses between these two 
models, those differences are relatively small and are not thought to be significant. 

The 1992 CNDB has its maximum annual return mass requirements occurring at a 
later time than shown in the 1990 CNDB. Again this can be attributed to a stretch 
out of the SSF program. However, it is significant to note that the 1992 CNDB has 
larger return mass requirements than the 1990 CNDB, although the absolute value 
of these differences is relatively small. 

Conclusions 


This study has shown that although there are some differences between the SSF 
transportation requirements identified in the 1990 and 1992 CNDB's, these 
differences are relatively small and do not alter the conclusions of this study. 

The annual differences in mass delivery and return requirements reflect the normal 
adjustments in payload manifesting as missions are planned and flown. This is not 
expected to alter the conclusions of this study because, in general, slightly higher 
manifesting rates in any given year are compensated for in other years by 
correspondingly smaller rates. This conclusion is enhanced by reviewing the 
cumulative mass delivery and retrieval rates. It becomes obvious that the data in 
the 1992 CNDB can be viewed as a time-shifted version of the data from the 1990 
CNDB. That is to say, the total mass transport requirements have not changed, only 
the schedule for delivering those masses has been shifted by 12 to 18 months to 
accommodate on-going changes in the overall schedule of the SSF program. 
Likewise, there are no significant differences in maximum delivery or retrieval 
rates. The changes in other payload requirements were not examined, since SSF 
comprises two-thirds of all transportation requirements, and is, by far, the largest 
driver to an architecture's required flight rates. None of the factors investigated 
gives any reason to alter any of the conclusions of this study. 


3.5.2 Attribute Model Refinements 


3.5.2.1 Safety Model Refinement 

The current method for estimating the number of crew loss events has a qualitative 
step whereby a judgment is made on the failure distribution across six primary 
causes of flight emergency: explosion, fire, loss of control, damaged vehicle, 
hazardous environment, or benign. 
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This process, developed by Boeing Defense and Space Group, allocates mission 
failures to specific causes, and then assesses immediate crew survival and abort 
probabilities. Values for each were developed by Boeing through an expert opinion 
process based on system configuration and ascent flight phase. To define this model, 
effort was focused on failure allocation and replacing expert opinion with historical 
failure types and relative occurrence by stage. The data base used to define these 
relative failure rates was the same as that used to develop engine and stage 
probability of success values for the PMS attribute. As part of this tool enhancement 
process, a more rigorous error checking on the original values was performed and 
the impact of discovered discrepancies was noted. Findings due to a new failure 
allocation process were shown relative to the original and updated (due to process 
errors) Human Safety values. 

Two other options for enhancing Human Safety were considered and rejected due to 
time and budget constraints. One option required a geometric definition sufficient 
to develop metrics for crew module location relative to propellant tanks, solid 
boosters, engine position, explosive yields, and crew escape methods. This was 
rejected primarily due to the lack of, restricted, or dynamic state of, system design 
data for new concepts (AMLS, AMSC, NLS, SSTO-VTOHL, NDV). The other option 
called for extending the PMS success trees along the mission failure branches by 
adding failure types, probable rate of failures, and an uncertainty band. Cumber- 
some documentation and the fact that the selected approach provides similar 
insight and product were reasons for excluding this option. 

Failure scenarios were devised for each of the six failure types defined during the 
original study (see Figure 3.5.2.1-1). The trigger event shown is the failure type, the 
protective event (against crew loss) is the inherent system design which precludes 
immediate loss of life, while the mitigating event is the system's abort capability. 
Estimated crew survival rates in each mission phase is the sum of PMS and the 
product of mission failure rate (1-PMS), probability of immediate survival (P s ), and 
probability of successful abort (Pa)- Failure at either the protective or mitigating 
event results in crew loss. Virtual scenarios (a spreadsheet of failure allocations, 
probability of immediate survival, and probability of abort) were created for all 
ascent phases of each piloted system. 
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Figure 3.5.2. 1-1.- Failure scenario description for crew loss events. 


A new approach to quantifying the frequency of each failure type was employed as 
an enhancement to the original expert opinion approach. Using the same data base 
that established the probability of success for liquid engines, solid motors, and 
propulsion systems, previous failures were categorized by type and their relative 
frequency was noted by stage (Table 3.5.2.1-1). 
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TABLE 3.5.2.1-1.- HISTORICAL LIQUID ROCKET FAILURE DATA 


Published Cause 
Of Failure 

First 

Stage 

(%) 

Second 

Stage 

(%) 

Third 

Stage 

(%) 

All 

Stages 

(%) 

Control 

18.92 

20.00 

0.00 


Electrical 

13.51 

8.00 

11.76 

11.39 

Explosion 

21.62 

4.00 

0.00 

11.39 

Fuel 

8.11 

16.00 

5.88 

10.13 

Frozen Valve 

0.00 

0.00 

17.65 


Guidance 

8.11 

4.00 

11.76 

7.59 

Hydraulics 

2.70 

12.00 

0.00 

5.06 

Ignition 

0.00 

16.00 

17.65 

8.86 

Lubrication 

2.70 

0.00 

0.00 

1.27 

Propulsion 

24.32 

12.00 

35.29 

22.78 

Separation 

0.00 

8.00 

0.00 

2.53 

Totals 

100.00 

100.00 

100.00 

100.00 


In order to retain the defined process for determining crew loss event rates, it was 
necessary to map the failure types from Table 3.5.2.1-1 into the previously defined 
categories: fire, explosion, loss of control, damage to vehicle, crew environment, 
and benign. Control and explosion are the only categories that map directly from 
history to the previously defined list. The balance of historical failures tend to be 
immediately benign to the crew. However, propulsion and separation failures were 
mapped into two different categories (propulsion - fire or benign; separation - 
damage to vehicle or benign), creating a range for probability of crew loss. In 
addition, for those systems with solid motors, their historical failure rate was added 
to the percentage of explosions, reducing the benign failure rate. Figure 3.5.2.1-2 
illustrates this mapping process. 
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Figure 3.5.2. 1 -2 - Mapping of historical failure types into previously 
defined categories. 


Findings 

Relative failure rates shown in Table 3.5.2.1-2 were allocated at the stage level, using 
the following guidelines: first stage rates were applied to any and all stages or 
engines that ignited at ground level; second stage rates were applied to any and all 
stages that ignited at altitude, except for the circularization stage; and third stage 
values were assigned to the circularization stage only. The last column is shown for 
information purposes only. 
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TABLE 3.5.2.1-2.- COMPARISON OF CREW LOSS EVENT RATES 


System 

Was 

Corrected 

New-Low 

New-High 

AMSC 

0.008340 

0.008337 

0.009264 

0.006979 

Beta II 

0.006240 

0.010528 

0.009818 

0.006105 

MLS-HL/CLV 

0.006410 

0.007080 

0.007793 

0.006467 

MLS-X/RPC 

0.005430 

0.005228 


0.003676 

NLS-2/RPC 

0.005420 

0.005225 

0.004990 

0.003671 

TITAN IIS/RUPC 


0.009065 

0.009266 

0.007706 

HR Titan IV 

0.012370 

0.010528 

0.011975 

0.010101 

Space Shuttle 

0.022350 

0.022350 

0.023228 

0.017550 

Shuttle Evo 

0.022780 

0.017792 

0.022338 


SSTO-VTOHL 

0.007020 

0.007024 

0.Q12650 

0.006005 | 


While applying this process to the piloted systems, differences were found in 7 of 10 
systems addressed (MLS-HL/CLV is identical to MLS-HL/LRV/RPC and is 
documented as a single system), and it was found that the range in crew loss 
frequency can be very large, depending on the severity of propulsion problems and 
frequency of separation problems. However, the two methods do provide similar 
values in terms of flights between crew loss events (Tables 3.5.2.1-2 and 3.5.2.1-3 and 
Figure 3.5.2.1-3), i.e., the corrected values are within or near the range predicted 
using historical failures and their relative occurrence. 


TABLE 3.5.2.1-3.- MEAN NUMBER OF FLIGHTS BETWEEN 

CREW LOSS EVENTS 


System 

Was 

Corrected 

New-Low 

New-High 

AMSC 

119.9 

120.0 

107.9 

143.3 

Beta II 

160.3 

95.0 

101.9 

163.8 

MLS-HL/CLV 

156.0 

141.3 

128.3 

154.6 

MLS-X/RPC 

184.2 

191.3 

200.2 

272.1 

NLS-2/RPC 

184.5 

191.4 

200.4 

272.4 

Titan IIS/RUPC 

96.8 

110.3 

107.9 

129.8 

HR Titan IV 

80.8 

94.9 

83.5 

99.0 

Space Shuttle 

44.7 

44.7 

43.1 

57.0 

Shuttle EVO 

43.9 

56.2 

44.8 

56.7 

SSTO-VTOHL 

142.5 

142.4 

79.0 

164.9 
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Figure 3.5.2.1-3- Projected flights between crew loss events. 


The new range of crew loss events per system and architecture, by "If', are compared 
against the original values in Table 3.5. 2.1 -4. This new process shows the 
uncertainty in crew loss events and relative architecture goodness. 
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TABLE 3.5.2.1-4 - CREW LOSS EVENTS COMPARISON 


8 

O 

k 

LL 

X 

o 

X 

3 

z 

o 

o 

5.60 | 

6.70 | 

4.50 | 

o 

CM 

3.30 | 

O 

5.80 | 

6.90 I 

O 

O) 

CD 

o 

o 

1^ 

7.50 1 

o 

CM 

CD 

o 

d 

o 

CO 

1^ 


IF H E“ HIGH... | 

X 

o 

X 

$ 

LD 

z 

9.00 | 

6.70 | 

O 

■*fr 

CO* 

5.20 | 

5.00 | 

3.50 I 

4.70 | 

6.60 1 

7.70 | 

o 

co 

h- 

O 

00 

8.90 | 

1 069 

O 

CO 

in 

o 

o 

d 

$ 

3 

5 

ID 

2 

o 

CO 

in 

o 

CO 

■M- 

o 

o 

uo 

o 

CO 

O 

CO 

CO 

2.50 

3.50 

3.50 

o 

CM 

t n 

O 

in 

5.30 

5.70 

O 

h- 

3.80 

5.00 

5 

3 

5 

LD 

z 

6.80 

5.30 

6.40 

3.90 

o 

o 

2.70 

3.70 

3.90 

08S 

5.90 

5.90 

6.90 

5.20 

o 

co 


Ifr 

3 

_J 

< 

> 

9 

.a 

o 

h- 

CD 

o 

CO 

6.40 

4.30 

3.90 

3.30 

o 

CM 

Tf 

o 

CM 

09*9 

o 

CD 

CD 

6.80 

7.20 

6.10 

4.60 

o 

uo 

CD 

3 

3 

< 

> 

Q 

3 

Si 

o 

CO 

5.80 

o 

CO 

5.00 

4.70 

3.50 

4.50 

4.70 

7.50 

o 

CD 

7.60 

o 

GO 

6.90 

5.20 

o 

CM 

d 

k 

CO 

k 

LL 

s 

X 

£ 

z 

3.40 

0 

01 
CO 

o 

CO 

o 

CO 

2.60 

2.00 

o 

o> 

CM 

o 

o> 

CO 

3.40 

3.40 

3.40 

o 

CO 

o 

CD 

3.00 

3.90 


IF N E" LOW... 

X 

o 

X 

£ 

z 

8.30 

o 

o 

CD 

7.70 

5.00 

o 

CO 

3.30 

4.50 

6.20 

7.50 

7.60 

7.60 

8.50 

o 

m 

CD 

5.00 

o 

00 

1 

5 

ID 

Z 

2.60 

2.50 

2.60 

2.60 

2.10 

1.50 

2.30 

orz 

2.60 

2.60 

2.60 

o 

CD 

CM 

3.50 

2.40 

2.60 

1 

3 

5 

LD 

Z 

6.30 

4.70 

5.80 

o 

00 

CO 

o 

CO 

co 

2.60 

3.60 

3.70 

5.70 

o 

in 

5.80 

6.60 

5.00 

o 

o 

o 

o> 

in 

UJ 

3 

3 

< 

> 

O 

3 

o 

3.30 

o 

00 

oj 

o 

CO 

co 

o 

CO 

CO 

2.50 

1.90 

2.80 

2.80 

3.30 

3.30 

3.30 

3.30 

4.40 

o 

cr> 

CM 

3.90 

LD 

3 

3 

2 

Q 

_J 

O 

o 

o 

CO 

5.30 

o 

o 

CO 

4.50 

3.40 

4.30 

4.50 

7.30 

o 

co 

7.40 

o 

co 

6.70 

5.00 

8.90 

k 

< 

s 

u. 

X 

£ 

X 

o 

CO 

o 

r>. 

o 

CO 

o 

CO 

o 

o 

0.90 | 

o 

o 

1.30 

o 

CO 

T*“ 

o 

CO 

r— 

o 

00 

o 

GO 

o 

CO 

T* 

1.30 

2.30 


IF "D"... 

X 

O 

X 

£ 

z 

7.90 

5.60 

7.20 

4.90 

4.60 

3.20 

4.40 

6.00 

7.40 

7.50 

7.50 

8.30 

6.30 

o 

CO 

8.40 

I 

$ 

ID 

z 

1.30 

1.40 

1.30 

o 

CO 

o 

CO 

d 

0.60 

o 

CO 

d 

o 

o 

1.30 

O 

CO 

1.30 

O 

CO 

1.00 

o 

o 

o 

uo 

3 

s 

ID 

Z 

5.90 

4.40 

5.50 

3.70 

3.70 

2.50 

3.50 

3.60 

5.60 

5.60 

5.70 

6.40 

4.70 

3.90 

5.80 

UJ 

3 

3 

< 

> 

O 

o 

1.70 

1.50 

o 

o 

1^. 

o 

o 

o 

CO 

o 

o 

o 

060 

1.70 

1.70 

1.70 

1.70 

o 

CO 

1.20 

o 

CM 

LD 

3 

< 

> 

O 

3 

_o 

7.60 

4.90 

o 

o 

i^* 

4.70 

4.30 

o 

CO 

CO 

o 

CM 

o 

CO 

o 

CM 

7.20 

o 

CO 

| 7.90 

1 6.50 

1 4.70 

o 

r^. 

CO 

DESCRIPTION 

I 

EVOLUTION 

NLS/CTV 

NLS/RPC/CRV | 

MLS-HL/CLV | 

£ 

2 

MLS-HL/RPC/LRV 

SSTO-VTOHL 

NLS-50/RPC 

NLS-50/RPC 

NLS- 50/RPC 

MR TITAN IV/RPC 

AM SC 

TITAN ll/RUPC 

BETA II 


I 


1 

EVOLUTION 

NLS/CTV 

NLS/RPC/CRV 

3 

O 

2) 

X 

CO 

3 

2 

MLS-X/RPC 

S 

c3 

CL 

§ 

X 

CO 

3 

2 

SSTO-VTOHL 

NLS-50/RPC 

NLS-50/RPC 

NLS- 50/RPC 

! MR TITAN IV/RPC 

| AMSC 

Odnu/ll NVJLI1 

BETA II 

| 

- 

OJ 

CO 


to 

CD 

r- 

CO 

T— 

CM 

CO 


CD 

f^. 

CO 


i 

- 

CM 

CO 


w 

CD 

r- 

00 


CM 

CO 


CD 

r- 

CO 


3.5-27 


Rev. E 











The following table (Table 3.5.2.1-5) summarizes mathematical errors discovered in 
the original process during this task. These corrections are the basis for the 
differences between the "Was" and "Should Have Been" values for probability of 
death (Pd) and mean flights between crew loss events. 


TABLE 3.5.2.1-5.- CORRECTIONS TO PREVIOUS HUMAN SAFETY PROCESS 



Phase 

Failure 

Correction 

Beta II 

2 

Benign 

Changed 85 To 80 So Total Failures Total 100 Rather Than 
105. 


3 


Pd Changed To 0.00004 (Product Of 1*0.08* 0.05), It Was 0.05. 

MLS-H1/CLV 

9 


Change 89 To 88 So Failures Total 100 Rather Than 101 

MLS-X/RPC 

6 

mm uH 

Changed 89 To 88 So Failures Total 100 Rather Than 101 


8 

wmssm i 

Changed 89 To 88 So Failures Total 100 Rather Than 101 

NLS-2/RPC 

6 


Changed 89 To 88 So Failures Total 100 Rather Than 101 


8 

BB 

Changed 89 To 88 So Failures Total 100 Rather Than 101 j 

Shuttle 

Evolution 

3 

Benign 

Changed 29 To 55 So Failures Total 100 Rather Than 74 

Titan II/RUPC 

9 

■39 

Changed 89 To 88 So Failures Total 100 Rather Than 101 

HR Titan 
IV /RPC 

1 

Explosion 

Changed Pd From 0 To 0.038 To Reflect Product Of Failures, 
Ps And Pd. 


9 

Benign 

Changed 89 To 88 So Benign Failures Total 100 Rather Than 
101 


Discovered math errors did not have a major impact on architecture ranking within 
the Human Safety attribute except for Architecture 18 (Beta n). The corrected error 
reduced flights between crew loss events from 160.3 to 95.0, which translated into an 
architecture ranking change from 8 or 9 to 15 for "Ifs" C through E-High. In "If" A, 
Architecture 18 was already ranked fifteenth of 15 and in "If* B, its rank dropped 
from fifth to fifteenth. 

Using historical data to allocate failures into the six categories identified in the 
original process provides a band of uncertainty for Human Safety. This band is due 
to the allocation of propulsion failures to either the fire or benign categories and the 
allocation of separation failures to either the loss of control or benign categories. In 
general, the corrected system values fall within the band created under the new 
method of failure allocation, except for MLS-X/RPC and NLS-2/RPC, where the new 
minimum is 200 flights between crew loss events versus the corrected value of 191. 
The various band widths of each system cause considerable changes in architecture 
rankings when comparing cases using the maximum or minimum flights between 
crew loss events. Scrutiny of the HTS Human Safety calculation process should be 
continued, and should focus on determining the probability of survival and 
probability of abort to ensure consistent treatment across all systems with similar 
configurations and mission phases. 
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3.5.2.2 Probability of Mission Success Attribute Model Refinement 

During the study extension period, two changes were made to the PMS model. 
These are detailed below. 

Launch Pad Hold-Down 


A function was added to the PMS model to account for the effects of launch pad 
hold-down on vehicle reliability. A review of historical launch data and a 
presentation on launch vehicle failure probabilities 2 indicated that over 50 percent 
of propulsion system failures develop within 5 seconds after engine start. The HTS 
study team decided that the ascent failure rate of liquid engines started on the pad 
should be reduced by half if a vehicle had a hold-down period (to determine engine 
health) prior to lift-off. The following is an example of how the equations were 
modified: 


Phase 1 - SSME ignition and thrust buildup 
R p l = ARV8 * RSll/4 * (RL3)l/4 
Example Modification: 

Phase 1 - SSME ignition and thrust buildup 

Rpl = ARl/8 * SQRT(RSll/4 * (rl3)1/4) 

Note: for probability of success numbers greater than or equal to .91, the square root 
of reliability is mathematically equivalent to reducing the unreliability by half. This 
simplified approach was used to develop these equations. 

QMS Engine Redundancy 

In developing the PMS value for each system in the HTS architectures, all liquid 
engines and liquid stages, from first stage through orbit circularization, were treated 
identically and assumed to have the same reliabilities. This produced a lower PMS 
value than would be expected due to redundancy inherent in the orbit 
circularization stage of piloted vehicles. For example, first- and second-stage liquid 
propulsion systems have single-string propellant lines and valves between the tank 
and engines. However, the Space Shuttle OMS system consists of two separate pods, 
with cross feed capability from the left pod to the right engine, and vice versa. Also, 
each propellant line has redundant valves between the tank and engine. This 
provides redundancy in the propulsion stage that had not been accounted for in the 
current process. In addition, there are generally-dual OMS engines, each capable of 
performing the circularization process independently. 

Because the stage reliability number is based on a single flow path between tanks 
and engines, it was decided to incorporate OMS redundancy into the PMS model. 
Probability of success equations were developed for each system that reflect this 


3.5-29 


Rev. E 



configuration and all of the possible success paths for functioning of the orbit 
circularization engines. These equations were then added to the model. 

System Results 

Table 3.5.2.2-1 contains the PMS values for the launch vehicles used in this study. 
Additional columns show the results of accounting for hold-down and OMS engine 
redundancy refinements. 


TABLE 3.5.2.2-1.- PMS VALUES 


Vehicle 

Original 
Study Results 

With 
Hold down 

With OMS and 
Hold down 

AMSC 

0.9577 


0.9770 

Atlas HAS 

0.9326 



Atlas EVOL 

0.9369 



Beta II 

0.9652 



Delta 

0.9319 



MLS-X (CTV) 

0.9455 

0.9528 

0.9572 

MLS-X (RPC) 

0.9544 

0.9618 

0.9618 

MLS-X (non SSF) 

0.9842 

0.9919 


MLS-HL (NUS) 

0.9691 

0.9767 


MLS-HL (CTV) 

0.9499 

0.9573 

0.9595 

MLS-HL (RPC/LRV, CLV) 

0.9543 

0.9617 

0.9617 

NLS-20 

0.9435 

0.9519 

0.9519 

NLS-50 (CTV) 

0.9455 

0.9528 

0.9572 

NLS-50 (RPC) 

0.9544 

0.9618 

0.9618 

NLS-50 (NUS) 

0.9842 

0.9919 


NLS-50 (AUS) 

0.9455 

0.9528 


NLS-HL (CTV) 

0.9308 

0.9380 

0.9423 

NLS-HL (CRV) 

0.9309 

0.9381 

0.9762 

RCV 

0.9290 

0.9394 

0.9584 

SSTO 

0.9691 

0.9768 

0.9768 

Space Shuttle 

0.9431 

0.9537 

0.9730 

Shuttle Evolution 

0.9290 

0.9394 

0.9584 

Titan II 

0.9626 



Titan III 

0.9474 



HR Titan II 

0.9323 

0.9417 

0.9562 

Titan IV (Centaur) 

0.9100 



Titan IV (NUS) 

0.9474 



HR Titan IV (RPC) 

0.9189 

0.9426 

0.9426 

Titan IV (CTF/LRV) 

0.9242 


0.9307 

Titan Evolution 

0.9519 



Titan Evolution/Centaur 

0.9186 
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In looking at the original study results, the NLS and MLS vehides scored well 
primarily due to the engine out capability of the first stage and OMS engines. When 
hold down effects are accounted for, the engine-out capability in the first stages is 
less significant. The final change reflecting OMS engine redundancy results in a 
higher reliability value for the Space Shuttle. 

It is important to note that the purpose of this analysis and of the PMS calculation 
methodology development in general was to provide a way of comparing relative 
reliabilities of different launch systems, and not to develop a point reliability value. 
In addition, since the avionics reliability value was a single multiplier used on till 
systems and did not contribute any comparative information, it was eliminated 
from the final score. 


3.5.2.3 Alternate Ground Operation Attribute 

During the HTS Study basic contract period, the NIT defined the LSC attribute as an 
indication of any given architecture's ability to meet its launch schedules. The LSC 
was a combined measurement of three subattribufes: Schedule Compression, 
Schedule Margin, and Percentage of Flights with Delays. Schedule Compression and 
Schedule Margin provided an intuitive measurement of architecture and flight 
system resiliency or the ability to effect schedule recovery. The Percentage of Flights 
with Delays was a measurement of architecture and flight system availability or 
dependability, based upon an unscheduled maintenance data base derived from a 
given flight systems mass, complexity, and mission length. The deficiencies in this 
methodology are that both the Schedule Compression and Schedule Margin 
subattributes failed to sufficiently address the relative differences in the proposed 
launch system designs. The Percentage of Flights with Delays subattribute value was 
partially derived from the estimated mission length, which is a valid parameter for 
reusable flight systems only. In addition, it was felt that the attribute gave 
insufficient insight into how system design choices would affect the ability to 
operate a proposed system. For these reasons, an alternate approach was considered. 

This new ground operability attribute (GOA) definition was refined to consist of the 
probability of achieving any given launch date, or sustaining any given launch 
manifest, for any given launch system or space transportation architecture. This 
revised attribute is expressed as a relative value or Figure of Merit (FOM), rather 
than an absolute value. The preferred methodology selected in this study measures 
this attribute as a function of the scheduled event burden plus the unscheduled 
event burden. The scheduled event burden is equal for all launch systems and all 
architectures since it is requirements-driven and is therefore a non-discriminator. 
The remaining variable in the equation is the unscheduled event burden. The 
unscheduled event burden is defined as a function of the weighted utility of a series 
of ground operation's complexity factors or subattributes. 
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The 10 ground operation's complexity factors are described below. The complexity 
factors were down-selected from a lengthy candidate list and represent only the 
value-added factors that may effect LSC and the unscheduled event burden variable. 
The weight percentages and utility values were developed through the application 
of engineering judgment by a team of launch site engineers with operations 
experience in the ground processing of the Space Shuttle, Atlas I, Titan HI, Titan IV, 
Centaur upper stage, and Fleet Ballistic Missiles. 

(1) Number of Fights is the total number of flights for all launch systems in the 
selected mixed fleet manifest. The analysis is at the architecture level, weighted 
at 14.1 percent. 

(2) System Commonality is the ratio of common types of flight elements to the 
total types of flight elements for all launch systems in the selected mixed fleet 
manifest. The analysis is at the architecture level, weighted at 10.8 percent. 

(3) Number of Elements is the total number of significant flight elements for each 
launch system in the selected mixed fleet manifest. The analysis is at the 
launch system level, weighted at 11.7 percent. 

(4) Crew Rating is the factor which distinguishes between a crew-tended and 
untended launch system configuration. A high value mission with no crew is 
also addressed under this complexity factor. The analysis is at the launch 
system level, weighted at 12.5 percent. 

(5) Processing Concept distinguishes between the launch site processing concepts 
of Integrate on Pad (IOP), Integrate/Transfer/ Launch GTL), and mixed ITL/IOP. 
The analysis is at the launch system level, weighted at 6.7 percent. 

(6) Reliability is the complexity factor which addresses the predicted level of 
unscheduled system maintenance. The analysis is at the launch system level, 
weighted at 4.2 percent. 

(7) Number of Fluids is the total number of fluids for each launch system in the 
selected mixed fleet manifest. The analysis is at the launch system level, 
weighted at 10.0 percent. 

(8) Expendable/ Recoverable Hardware is the complexity factor which distinguishes 
between recoverable or refurbishable, and expendable flight hardware. The 
analysis is at the flight element level, weighted at 9.2 percent. 

(9) Propellant Type is the propellant (if any) utilized by the flight element. The 
analysis is at the flight element level, weighted at 7.5 percent. 
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(10) Number of Significant Components is the total number of significant 

components for each flight element. The analysis is at the flight element level, 
weighted at 13.3 percent. 

A total of 40 existing ETO launch systems or conceptual ETO launch system designs 
were identified and incorporated into the various HTS architecture options by the 
NIT. For each launch system, a complexity factor data sheet was developed using 
resource data provided by the NIT or extracted from HTS Study interim reports and 
other current source material defining the existing or proposed launch system 
configurations. 

Figures of Merit for this attribute were calculated for each launch system and 
architecture. Refer to Volume II, Appendix B.1.10 for a summary of the analysis. 

The FOM's for the individual launch systems varied from a low value of 0.5947 for 
the conceptual SSTO configuration to a high value of 0.8836 for the conceptual NLS- 
20 configuration. In general, the reusable human flight systems ranked lower than 
the expendable flight systems. The relative rankings of the existing Atlas, Delta and 
Titan launch system configurations are comparable. These results are intuitive, and 
consistent with the experience base for ground processing of domestic launch 
systems. 

The FOM's for the architecture options vary from a low value of 0.5036 for 
Architecture 8 (Advanced Technology Phasing /SSTO) to a high value of 0.7288 for 
Architecture 17 (New Concept Option/RUPC). Architecture 2 (Shuttle Evolution 
Option) is the preferred architecture, based on the highest average FOM across all 
architecture options (A through E High). Architectures 8, 16 (New Concept 
Option/AMSC) and 18 (New Concept Option/TSTO Beta II) values rank at the low 
end of the distribution. These three architectures rely extensively on new, reusable, 
human flight systems. 


3.5.3 Improving System and Architecture Scores 
3.5.3.1 New ELV Cost Sensitivities 

Architectures 5 and 6 both scored well in the overall architecture evaluations. 
However, both have higher architecture costs than the reference. Architecture 1. 
Architecture 5 has high recurring cost in the early years due to the relatively high 
recurring production costs associated with the procurement of the reusable crew 
carriers. These costs occur in the years that the DDT&E costs are tailing off, with the 
combination producing the high peak costs in the years 1998 to 2003. Beyond 2003 
there is a quasi-steady-state period for the costs. To justify the high initial costs, 
these out-year costs must be substantially lower than those of the baseline 
architecture. Since the cost associated with the architecture is dominated by the 
annual costs during this time period, sensitivities to ELY costs were examined. 
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These sensitivities are shown in Figure 3.5.3.1-1. The effect on total architecture cost 
of varying different ELV cost categories, both singly and in combination over the 
architectural time frame, is presented in the figure. As can be seen, the single most 
sensitive cost (steepest slope) is associated with recurring production (as represented 
by the filled triangles). Conversely, wide variations in either non-recurring or 
operations cost produced relatively small variations in total cost. Also shown for 
reference is the total cost of Architecture 1, as represented by the horizontal dashed 
line. Within the range of the sensitivities shown, the reduction of no single cost 
category produced a cost for Architecture 5 which was at or below that of the 
baseline. Since the costs during the out-years was of greatest interest (in terms of 
justifying the up-front costs), the combination of recurring production and 
operations costs was investigated. This sensitivity, represented by the open triangles 
in the figure, showed that at a reduction of about 50 percent for both these cost 
categories. Architecture 5 costs were equivalent to those of the baseline. The actual 
required reduction in the combination of ELV recurring production and operation 
costs over the life of the architecture, for equivalence with Architecture 1, was 
calculated to be 50.33 percent. 



-50 -40 -30 -20 -10 0 10 20 30 40 50 

PERCENT CHANGE 


Figure 3.5.3.1-1- MLS cost sensitivity - Architecture 5C. 
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The recurring production cost of the new ELV's (MLS, NLS, Spacelifter, etc.) has a 
large effect on the total architecture cost due to the relatively high flight rate 
combined with the MLS design assumption of expendability. Reducing this cost in 
half, under the current design assumptions, is probably not achievable because of 
the large amount of expendable hardware. This realization led to the effort to define 
a partially reusable MLS design and evaluate its use in a revised architecture (5A). 

The partially reusable MLS concept, developed by Boeing, uses a module with SSME 
engines on the one and one-half stage and the addition of the equipment necessary 
to recover the engines and avionics from the stage. The half-stage engines are 
parachuted to the water in protective waterproof enclosures and recovered from the 
ocean, down range from the launch site. The engines and avionics on the first stage 
orbit once-around, reenter in a protective module, and parachute to a land recovery. 
These units are returned to the launch site, refurbished, and flown again on 
subsequent launch vehicles. As such, both the development and recurring 
production costs are appreciably lower than the new development ELV. 

Table B.l. 6.2-16 of Volume II shows vehicle cost input used for this comparison 
with the baseline Architecture 5. 

As can be seen in Figure 3.5.3.1-2, Architecture 5A shows a marked improvement in 
the annual cost during the operational phase (2003 and beyond), when compared to 
Architectures 5 and 1. All of the following comparisons are done for "If’ C, unless 
otherwise noted. 



Figure 3.5.3.1-2 - Architectures 1, 5, and 5A - "If" C annual cost comparison. 
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The net reduction in recurring cost is a result of the change in the concept from an 
all-expendable MLS (Architecture 5) to a partially reusable MLS (Architecture 5A). 
This concept change produced a reduction in the recurring production cost as seen 
in Figure 3.5.3.1-3. There was, however, a slight increase in the operations cost, due 
to the added requirement to refurbish the recovered components. 



1990 1995 2000 2005 2010 2015 2020 

YEAR 

Figure 3.5.3. 1-3.- Architectures 5 and 5A - "If* C recurring 
production cost comparison. 

The initial trade study identified a need to reduce the combination of recurring 
production and operations cost a factor of 50 percent to achieve cost parity with 
Architecture 1 ("If" C), not including the cost of unreliability. As can be seen in 
Figure 3.5.3. 1-4, the total of recurring and non-recurring cost for Architecture 5 A is 
still slightly higher than that for Architecture 1 in "If" C. When the cost of 
unreliability is added, the difference is reduced, since there is improved reliability of 
Architecture 5 A over 1. As can also be seen, the effect of reducing flight rate, "IPs" A 
and B, is to further reduce the cost of Architectures 5 and 5A compared to 
Architecture 1. 
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Figure 3.5.3.1-4- Architectures 1, 5, and 5A - "Ifs" A through D 
total architecture cost comparison. 


3.5.3.2 Space Shuttle Impacts 

3.5.3.2.1 Space Shuttle design improvements - The conceptual definition for 
Shuttle Evolution used in the study resulted in reduced PMS and equivalent 
Human Safety (crew loss events rate) relative to the current Space Shuttle system. 
Titan Evolution also resulted in a lower PMS relative to its current model. 

Since these attributes were highly weighted, it was attempted to redefine an 
evolution concept that provided improved PMS and a lower crew loss event rate 
than the current Orbiter stack offered in the Evolution Architecture. The ELV's in 
the Evolution Architecture would not be changed in this effort so the impact of 
Shuttle Evolution changes could be readily identified. 

Suggested improvements were to: (1) retain SRB's in Evolution Concepts, (2) 
provide for crew module separation and recovery for Space Shuttle Orbiter, (3) use 
hybrid boosters instead of liquids, and (4) retain SRM's on HR Titan IV. 

For Shuttle Evolution redefinition, three key changes would have a dramatic 
impact on our attribute values: retain ASRM's, replace them with hybrids, or define 
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a means for crew escape for the entire mission. Retention of ASRM's will maintain 
the Reference Architecture's PMS value. With increased crew survival due to the 
addition of ejection seats and the reduction of piloted missions due to the RCV, 
Human Safety should be improved dramatically. Hybrids will offer a less degraded 
PMS than liquids but should regain credit due to non-catastrophic failure and 
shutdown capabilities. Applying a means for crew escape over the entire ascent 
phase will greatly decrease the number of crew loss events. Due to the way the 
Evolution Architecture was manifested, only non-SSF flights will see an increase in 
flight quantity due to loss of performance caused by the addition of the frangible 
seam and recovery system of the CEM. 

Shuttle Evolution, including the RCV, is redefined as follows for this analysis: 
ASRM's replaced by HRB's is with identical performance as the LRB's used 
previously; ejection seat concept replaced by separable crew module with lanyard 
rocket ejection capability; and manifest crew exchange flights to capacity, with 
remaining cargo placed on RCV. All other aspects of Shuttle Evolution as initially 
defined remain the same. A summary of attribute input data is shown in 
Table 3.5.3.2-1. 


TABLE 3.5.3.2-1.- SUMMARY COMPARISON OF "IF” C FINDINGS 
FOR SHUTTLE EVOLUTION U 


Attribute 

Reference 

Evolution 

Evolution II 

Improvement 
(EVO To 
EVO H) 

Architecture Cost Risk 





Tech Challenge 

168.700 

370.800 

419.000 


Program Immaturity 

1.000 

2.740 

2.754 


New Systems 

0.970 

2.600 

2.600 

mmm 

Environment 

27825450 

2067017 

2086503 

(19486) 

Funding Profile (M$92) 





Total 

177,404 

209,653 

224,537 

(14884) 

Peak Year 

7303 

11485 

13605 


Human Safety 

6.7 

4.8 

4.1 


(Crew Losses) 





LSC 





Compression 


0.408 



Margin 

4.429 

5.684 

5.474 


Delays 


12.000 

12.200 


PMS 

0.9374 

0.9354 

0.9363 

0.0009 
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Data required for complete analysis included: a recheck of flight rates based on a 20k 
reduction in Orbiter capacity with the separable crew module (report estimated 
15k - add-on of 33 percent additional assumed) and fully-manifesting crew exchange 
missions; recalculate PMS based on HRB stage reliability of 0.99232 (square root of 
0.9847 due to single fluid path) and HRB engine reliability of 0.99491 (square root of 
product of liquid engine and segmented solid engine reliability); reestimation of 
probability of survival and abortability based on separable crew module; 
reestimation of program risk; propellant quantities for environmental; and cost 
estimates for new orbiters to replace existing fleet at one per year from 2000. It is 
assumed that schedule delays will not be appreciably changed for Shuttle Evolution 
with this modification to the Orbiter. 

Table 3.5.3.2-2 shows a comparison of attribute values for Space Shuttle, Shuttle 
Evolution, and Shuttle Evolution II Architectures, "If" C. A full assessment of the 
changes made to Shuttle Evolution is to be completed. 


3.5.3.2.2 Cost reduction impacts - The objective of this "quick-look" analysis effort 
was to assess the impact of a fixed per-year reduction in resources on the Space 
Shuttle flight rate and total architecture cost. 

Using the study attribute and architecture analysis tools, Rockwell incorporated a 
fixed percentage reduction in Space Shuttle costs with 1992 as the base year and each 
subsequent year being reduced, relative to the previous year, by that fixed 
percentage. The reduction per year was defined so that a total cost reduction of 5, 15, 
30, and 50 percent was realized by 1997. This was used because the HTS Funding 
Profile attribute is a summation of costs for flights between 1998 and 2020, inclusive. 
Figure 3.5.3.2.2-1 shows the results of this analysis. Based on this analysis, a good 
rule of thumb is that for every one percent decrease in Space Shuttle operations cost 
achieved by 1998, the HTS Reference Architecture totcil cost is reduced by $1B. 
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TABLE 3.5.3.2-Z- EXTENSION TASK INPUT DATA FOR SHUTTLE EVOLUTION II 


Attribute 

Previous 

Value 

New 

Value 

Human Safety 



Separable Module (Figure) 

N/A 

Entire Mission 

Crew Escape (Figure) 

Ejection 

Extraction 

Funding Profile 



DDT&E 



Orbiter * 

$1,966 B(92) 

$6.7 B(90) 

Booster A 

$1,140 B(92) 

Same As LRB 

First Unit 



Orbiter # 

$1,756 B(92) 

In DDT&E 

Booster A 

$0,176 B(92) 

62% Of LRB 

Production 



Orbiter # 

$1,756 B(92) 

$2.5 B(90) 

Booster A 

$0,176 B(92) 

62% Of LRB 


@ 90% Lc/88% 


Fleet Replacement Logic 

Rc 

1/Yr (2000-2004) 


Attrition 

+ Attrition 

PMS 



Booster Stage Success Rate 

0.9847 

0.99232 

Booster Engine Success Rate 

0.9977 

0.99491 

ACR 



Technical Challenge 



Non-Recurring Costs 

3 

4.2 

Production 

2 

2.8 

Operations 

3 

3.6 

Program Immaturity 

4 

4.0 

Number Of New Systems 

0.93 

1.0 

(Figures Attached) 



LSC 



Schedule Compression 

85/128 

85/128 

Schedule Margin 

797.42 

797.42 

Percent Delays 

24.02 

24.02 

Environmental Impact 



Liquid Oxygen 

2032.9 Klb 

2951.9 Klb 

Liquid Hydrogen 

227.6 Klb 

227.6 Klb 

RP-1 

268.7 Klb 

N/A 

Solid Propellant 

N/A 

600.0 Klb 


“Spread over 8 years: 1, 4, 10, 15, 25, 30, 15, 5. 
A Use the same spread as for the LRB’s. 

#Use the same spread as for the Orbiter 
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Figure 3.5.3.2.2-1- Space Shuttle cost reduction impact on total architecture 
costs of HTS reference architecture. 


3.5.3.3 Improving Architecture Scores 

As a result of the work performed in the HTS study, and the extension, it was 
discovered that improved architectures could be found by learning from the 
shortcomings of the existing architecture set. Improving or modifying existing 
architectures, as well as looking at what a new, clean-sheet architecture would look 
like is discussed below. 

3.5.3.3.1 "Improved" architectures - Features of systems that score well in the HTS 
methods of quantifying attributes are listed in the following paragraphs. This is 
essentially a compilation of study findings; there are many other ways to improve 
each attribute, but some produce secondary improvements and/or cannot be 
measured by study metrics. It is interesting to note that, in some cases, the desirable 
vehicle concept features are contradictory across two or more attributes. 

a. Human Safety 

A system should feature full flight, envelope escape capability (maximize Pa), 
maximum separation of crew from propellants and propulsion (maximize Ps), 
and no SRM's (maximize time for warning and initiating abort). Also, a system 
should minimize correlated failure potential (maximize Ps and Pa) by physically 
isolating flight critical systems, such as control actuators, from sources of likely 
hazards (such as turbomachinery). 
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b. Probability of Mission Success 


High scores are obtained for those systems that have engine-out capability, 
ground start of as many engines as possible, hold-down on the pad, minimum 
number of engines, and a minimum number of staging events. 

c. Funding Profile 

(1) Peak Funding: Successful architectures and elements minimize new 
development, separate engine development from airframe development, 
incorporate appropriate reusability (relates to the total number of flights; 
however, some components designed for reuse may not be justified by some 
traffic model flight levels), and minimize recurring production buys during 
development or slide buys of recurring hardware until later. 

(2) Life Cycle Cost: Elements score well if they feature high reusability 
(minimize or eliminate recurring production) and if manifesting is done at 
most-favorable flight rates and payload levels. In addition, a system should 
be designed for 'operability' - here defined as minimizing fixed costs and 
short turnaround times, including minimizing the recurring production 
hardware introduced into the cycle. 

d. Architecture Cost Risk 

In an ideal situation, architectures ideally would minimize the number of new 
systems, minimize technology advances, and minimize development costs. 


e. Launch Schedule Confidence 

Successful architectures maximize number of operational sites, include the 
ability to launch with failures (minimum equipment list), plan for nominal one- 
shift operations, and plan on less than 80 percent facilities utilization. 

f. Environment 

The best scores are obtained with systems that feature no solid rocket motors and 
minimize the launch vehicle size for a given payload. 
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3.5.33.2 "Better" architectures - For the purposes of this section, an architecture is 
considered "better" within the context of the overall HTS study rather than the 
current set of architectures (i.e., using the consensus-based approach of determining 
weighted attributes deemed important to the customer). Therefore, one would 
conclude that the "best" possible architecture would be reflected in scoring higher in 
each and every attribute, rather than any other architectural option. Therefore, the 
approach for developing a better architecture starts with an examination of what 
design or operational features result in high attribute scores. As noted in the 
previous section, there are identifiable features of better scoring systems. An 
objective search of all concept options is then performed to reveal maximum 
correspondence between desirable features, and concept and architecture 
characteristics. 

The ideal architecture would meet all these constraints. Since some are 
contradictory, this is impossible, so the best architecture should conform with most 
of these constraints. At this point in the study, NIT members were invited to 
submit proposals for a "best" architecture. These architectures were compared to the 
reference architecture and Architecture 8 (SSTO), which scored the highest in the 
HTS architecture evaluation process using the NIT’s weightings of attributes. As a 
result, two architectures comprised of two similar launch vehicle families, are 
discussed below. 

Family "X" flies people and cargo together in a glider (although external shape is 
secondary to the findings) that can carry an eight-person crew and a 15 ft diameter by 
40 ft long payload bay. This is essentially a larger (135 klbs) version of the CLV, the 
40 klbs of payload capacity is more closely optimized to the manifesting 
requirements than the CLV. The launch vehicle is based on a family approach, 
whereby the development costs of the new systems are offset by improvements in 
reliability, safety, operability, and lower recurring production costs of all the vehicles 
in the architecture. Figure 3.5. 3. 3.2-1 depicts the vehicles used in the architecture. 
Engine-out capability, existing SSME’s (at 100 percent power level), all-engine 
ground start on human flights, and NLS-type health monitoring, etc., are all 
hallmarks of an architecture that would score well in the HTS architecture 
evaluation process. Note that other non-study considerations are addressed as well: 
heavy polar missions from ETR without overflights, an excellent commercial class 
launcher, and ready-growth path to current SEI launcher plans. 
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Figure 3.5.3.3.2-1.- Family "X". 

Family "Y" essentially separates the job of flying people and cargo, although the HTS 
findings would indicate that it is desirable to include some small amount of cargo 
on all human flights; the throw-weight capability of the launch vehicle (to SSF 
transfer orbit) is approximately 65 klbs, which is adequate for an eight-person crew 
and some limited cargo. Figure 3.5.33.2-2 depicts the elements of the architecture. 
The glider (again, shape is not that important) would be flown in two versions 
called "A" and "B". The external shape and many of the subsystems are identical. 

In configuration "A", there is a 15 ft by 22 ft cargo bay with no provisions for a crew; 
configuration "B" has accommodations for an eight-person crew and a small 
pressurized cargo compartment. The desirable features of the launch vehicles are 
similar to those explained for Family "X" above. 
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Figure 3.5.33.2-2.- Family "Y". 


The two reference architectures (Architectures 1 and 8) and the two proposed 
architectures are compared in Table 3.5.3.3.2-1. In this case, it is less the intent to 
propose a right answer than it is to show how using features of the current concepts 
and attribute weightings can derive new architecture options. It remains to be seen 
how future architecture can score better than the options proposed here, but it is 
likely that based on the analysis of attributes, better architectures than this original 
set can be formulated. 
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TABLE 3.5.3.3.2-1- ATTRIBUTE COMPARISON OF PROPOSED "BETTER' 
ARCHITECTURES WITH REFERENCE ARCHITECTURES 



Ref (1) 

"X" 

if y n 

SSTO 

Human Safety 





Escape Capability 


• 

• 

• 

Max Separation 


• 

• 

o 

No SRM’s 


• 

• 

• 

Min Correlation 


• 

• 


PMS 





Engine-Out 


• 

• 

• 

Ground Start 

O 

• 

• 

• 

Hold-Down 

o 

• 

• 

• 

Min Engines 

• 




Staging Events 


o 

• 

• 

Fund Profile-Peak 





Min New Dev 





Sep Eng A/F Dev 


• 

• 


Reuse /Init Buy 





Fund Profile-Total 





Reusability 


o 

o 

• 

Favorable Manifest 


• 

• 


ACR 





Min New Systems 

• 




Min Technology 

• 

o 

o 


Min Dev Costs 

• 




LSC 





Max Op Sites 




• 

Launch w/ failures 


• 

• 

? 

One Shift Operation 


? 

7 

? 

Fac Util <80 percent 


? 

7 

7 

Environment 





No SRMs 


• 

• 

• 

Min LV Size 


• 

• 

• 


• - Significantly Better 
O - Somewhat Better 
? - Need More Data 
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SECTION 4 

HTS FINDINGS: PUTTING IT ALL TOGETHER 


4.1 DETAILED FINDINGS BY ARCHITECTURE PATH 

The significant findings relevant to pursuing each of the possible paths are provided 
below. This information is provided to aid agency planners in determining how to 
best meet the nation's transportation needs. These results are also useful for 
understanding the consequences that may likely result along a potential path should 
they choose not to use attributes and their associated priorities in determining 
which path to follow. In other words, it quantifies the impact of a customer's 
decision. Of course, all findings, conclusions, and recommendations are based on 
the assumptions, methodologies, and data presented in this report. When findings 
lead to recommendations that can be substantiated by the data, they are dted in 
section 5.0 of this report. 

As a result of the HTS study, the NIT has developed the following findings and 
consequences that would be encountered as a function of the chosen path. Unless 
otherwise noted, findings apply to the "If" C activity level (continue current 
missions plus SSF PMC). Similar findings for the "If" B mission activity level 
(continue current missions only) can be obtained from the architecture data in 
Volume n. Appendix C. 

If we retain current systems, then the HTS process indicates that: 

• New Space Shuttle Orbiters are likely to be needed for future demand and/or 
probable losses, since the flight demand is driven by SSF deployment and 
support, and other transport. 

• An additional MLP is the only Space Shuttle facility element needed to support 
this implementation. 

• HTS needs model cannot be supported with the eight flight-per-year restriction 
on Space Shuttle. 

If we evolve current systems, then the HTS process indicates that: 

a. For the baseline Space Shuttle evolution compared with current systems 

• Total architecture costs increase $20B to $27B, with a $3B higher peak 
funding requirement and a $3 to 4B higher unreliability cost. 

• Crew loss events are reduced 12 to 34 percent. 

• Architecture risk increases 12 to 16 percent, inversely with activity level. 
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Piloted flights decrease by 0 to 90 from "If A through "If E-High due to the 
introduction of the RCV and increased Space Shuttle performance. 




• Unpiloted flights increase by 0 to 97 from "If A through "If" E-High due to 
the introduction of the RCV. 

• Mission success is not significantly affected. 

• Environmental impact is reduced 12 to 33 percent for "If's" A through 
E-High due to Space Shuttle LRB's. 

• Additional Space Shuttle facility elements are not required. 

b. For evolution including HRB's and CEM's compared with current systems 

• Piloted flights decrease by 45 with respect to current systems and increase by 
11 with respect to baseline evolution due to the introduction of the RCV, 
and the decreased Space Shuttle performance due to the addition of a CEM. 

• Unpiloted flights increase by 83 with respect to current systems due to the 
introduction of the RCV. 

• Mission success is not significantly affected. 

• Total architecture costs increased by $47.1 B over the current systems and by 
$14.8B over the baseline evolution case. In addition, the peak funding 
requirement was $6.3B higher than the current systems and $2.2B higher 
than the baseline evolution case. Unreliability costs were increased $6.3B 
over current systems and $2.2B over the baseline evolution case. 

• Crew loss events are reduced by 39 percent with respect to current systems 
and 15 percent with respect to baseline evolution. 

• Cost risk increases 13 percent with respect to current systems and 0.5 percent 
with respect to evolution architectures. 

• Environmental impact is decreased 25 percent with respect to current 
systems and increased 1 percent with respect to baseline evolution. 

• Additional Space Shuttle Orbiters are likely to be needed for future demand 
and/or probable losses. 

• The CEM's contributed less than 0.7 of 2.6 crew loss reduction. 
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If we replace current systems with new systems, then the HTS process indicates that 

• Significant improvements in safety can be achieved by several alternative 
transportation architectures. This is due to the addition of features such as 
vehicle hold-down on the pad, engine-out capability, abort capability during 
all ascent phases, and careful selection of the major propulsive systems. The 
additional cost to achieve this added safety ranges from $40B to $60B, for 
Architectures 5 and 6 respectively. 

If we augment the current systems with new systems, then the HTS process 
indicates that: 

• Total architecture costs increase $55.6B to $ 94.9B, with a $2.5B to $9.6B 
higher peak funding requirement and a -$6.4B to + $1.5B change in 
unreliability cost 

• Crew loss events vary from -48 percent to +7.5 percent 

• Architecture risk increases 15 percent to 40 percent 

• Piloted flights vary by -61 to +70 for "If' C through "If' E-High 

• Unpiloted flights increase by 68 to 222 for "If' C through "IP E-High 

• Mission success does not vary significantly 

• Environmental impact varies from -21 percent to +10 percent 


4.2 RESPONSES TO VIEWPOINTS 

Prior to the HTS study, there were several inconsistent viewpoints common among 
discussions concerning the need for a next transportation system. These viewpoints 
usually began with a statement born out of some frustration with the Space Shuttle, 
and were followed by some expression of desire for a replacement system. Too 
often, however, these viewpoints were contradictory and provided no useful 
direction for agency planners. We believe it is important to specifically respond to 
these viewpoints, since they impact discussions of whether or how new systems can 
or should be justified. 

As a result of having evaluated the data relative to these questions during the 
course of this study, and the extreme emphasis put on definition and measurement 
specifics during the HTS study, the NIT can provide their insightful responses to 
these conflicting viewpoints. 
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"The nation should not buy a new Orbiter OR the nation should continue to rely 
on the Space Shuttle for the next 20 to 30 years." 




Without taking attrition into account, the current fleet does not support 
transportation requirements which would continue current missions and 
subsequently add SSF build-up and support ("If" Scenario C), if it is necessary to 
fly the payloads in the year in which they are currently planned. However, the 
current fleet can support these requirements with the addition of an additional 
Space Shuttle Orbiter and a MLP. The bottom line is: the decision on the 
number of required orbiters in the future must be based both on potential 
attrition and the expected usage rate required to meet future demand. 

• "The Space Shuttle costs too much to operate." 

This viewpoint incorrectly assumes that operations costs are the dominant 
attribute the agency is trying to minimize, when in fact, minimizing the agency's 
annual expenditure on transportation is the objective we are trying to achieve. 

A decision made on only one component of cost (DDT&E, operations, or 
production of components) which comprises an annual expenditure will almost 
certainly be a bad one. Other than the single-stage-to-orbit (vertical take-off and 
horizontal landing) concept studied, the current transportation systems 
(Space Shuttle, Delta, Atlas, Titan) have the lowest total architecture cost 
(integrated annual expenditures from the present to 2020) based on current ways 
of doing business. All other Space Shuttle replacement architectures add at least 
30 percent to transportation costs over this study time period. This finding 
applies if we engage in transportation activity levels greater than or equal to 
assembly and support of SSF. For less aggressive transportation models, some 
architectures {5, 6, 7, 14, 16, 17 ("If" A)} and {14, 16, 17 ("If B)} become cost 
competitive with the current systems. 

• "We need alternate access to space in the event of an extended Space Shuttle 
downtime." 

To provide alternate access for people and cargo, the nation should be prepared 
to spend an additional $50 to $100 billion between now and 2020 to develop, 
operate, and maintain this capability. The range depends upon whether 
alternate access is provided for cargo-up only, cargo-up and -down, or people-and 
cargo-up and -down. The sheer expense of providing alternate access dictates 
that we develop a strategy for minimizing the contribution of non-technical 
reasons to "Space Shuttle downtime". 
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• "We should separate people from cargo in the name of safety." 

The presence of some cargo capability on the human-tended carrier was not 
found to have a deleterious impact on the number of crew losses that could be 
expected. 

• "We should separate people from cargo in the name of cost." 

The presence of some cargo on a personnel carrier can be cost advantageous 
when crew and cargo are being delivered to the same destination. This is 
especially true of vehicles with higher cargo capacity, given that the support of 
SSF comprises the majority of our transportation activity. 

As a replacement for existing systems, new systems currently under study which 
either combine or separate people from cargo are still more expensive than 
continued use of current systems. 


• "New systems based upon newer technology promise significant improvements, 
and therefore we need to develop new systems." 

SSTO, with its reliance on more advanced technology relative to many of the 
other options studied, would be a cost effective alternative to the Space Shuttle 
were it to actually achieve its stated cost goals. However, the low confidence 
level in the cost data provided puts this finding in serious question. 

• "There should be commonality between the ACRV and the next HTS." 

Architecture level trades, such as the HTS study, do not possess the fidelity 
required to evaluate this point. From a total architecture standpoint, whether a 
new personnel carrier should also double as the ACRV or not is a secondary 
concern, due to the relatively low cost and usage rate of the ACRV, and not a 
primary factor in determining the transportation system. Once that basic 
decision is made, assessing commonality with the ACRV would be in order. 


• "Air launch systems promise significant attribute improvements for any new 
transportation system." 

Candidate air-launched systems evaluated in this study did not fare well due to 
the small cargo levels and the resulting high flight rates associated with them. 
Life cycle architecture costs were still dominated by the cost of ELV's to fly heavy 
payloads. 
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SECTION 5 

CONCLUSIONS AND RECOMMENDATIONS 


5.1 CONCLUSIONS 

From the extensive work performed in this study, the NIT has gained a unique 
insight into the quality and consistency of work performed by both industry and 
government on candidate transportation systems. From this unique vantage point, 
the NIT concludes the following: 


a. Many of the systems defined in section 3.3.3 have sufficient definition so that 
vehicles in their class can be evaluated and specific systems down-selected 
without further study at the architecture level. (Of course, once the architectural 
path is selected, there would be additional system definition required.) 

"Sufficient definition" is defined here as either (a) haying enough level of detail 
in an absolute sense, or (b) improving the system definition beyond the current 
point is not warranted since architecture considerations dominate. Those 
concepts having sufficient definition at this time are: 

• MLS (NLS) 

• Space Shut tie /Shuttle Evolution 

• Beta II 

• AMSC 

• CLV 

• Titan (including human-rated versions) 

• personnel-only carriers (e.g., PLS, RUPC, etc.) 

b. Further system concept definition is required on the following concepts before 
they can be evaluated for their suitability in a future personnel transportation 
system. 

• SSTO 

• NASP-derived vehicles 

• advanced TSTO concepts (e.g., AMLS) 

• air-launched concepts 

c. Sufficient definition of potential new ways of doing business exists, and it is 
now t im e to quantify and verify these new business practices on the existing 

systems. 

d. Providing alternate access by developing new dedicated U.S. assets is not cost 
effective. 
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e. Significant improvements in crew safety were realized through the introduction 
of launch escape, engine-out, and hold down on new systems. 

f. There is no inherent safety benefit from separating crew and cargo. (This does 
not mean that untended payloads should be placed aboard human-tended 
vehicles. It means that if the crew will be working with the payload while in 
orbit, having both delivered on the same launch vehicle, in and of itself, does 
not adversely impact safety.) 


5.2 RECOMMENDATIONS 

The intent of the HTS study was to provide the information necessary for senior 
agency management to make a determination on the path to follow for the next 
HTS, and not to recommend the specific architecture. To reach recommendations 
on the transportation system for the future, the HTS study process requires 
prioritization of desired transportation attributes by the NASA administrator. Since 
he or she is the ultimate transportation customer and the executive branch's 
steward of the nation's space program, any recommendations are a direct function 
of his attributes and their relative priority. As a result, while the study did compare 
architecture options based on the team's assessment of missions and attributes, the 
study team is not able to recommend a preferred or optimal transportation 
architecture, or any specific concepts which are a part of them, at this time. 

However, the HTS study process provides a very valuable tool to aid the 
administrator's evaluation of options for the next human transportation system 
once his or her requirements are known. 

There are however, recommendations that can be made as a direct result of the 
experience gained during this study. They are: 

a. Development of Mission Requirements and Evaluation Criteria - Prior to 
deciding what the next transportation system should be, focus senior agency 
management on customer-desired attributes, their measurements, and 
mission requirements for new systems, rather than on system or vehicle 
concepts. Acceptance of this recommendation will allow convergence more 
quickly on the desired human transportation system. For a national program, 
space program managers, the DOD, and other potential users should be 
included in the working group to define desired attributes and their 
measurements. 

b. New Ways of Doing Business - Implement a plan for instituting new 
business practices immediately on existing systems. The plan should be 
constructed so that any actual savings realized should be "banked" first for 
verification accounting and confirmation purposes, before using the savings 
to pay for new programs. 
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Crew Escape Modules on Space Shuttle - Do not pursue retrofit of a crew 
escape module on the existing Space Shuttle fleet due to the high cost and 
small improvement in safety. 

Human-Tended versus Untended Transportation — Consider both the 
human-tended and untended aspects of transportation simultaneously (at the 
architecture level) when considering what the next human transportation 
system should be. 

Separation of People and Cargo - Do not pursue development of a 
transportation system which separates people from cargo in the name of 
increased safety. Architectural considerations (i.e., additional flight rates) and 
other transportation requirements were found to dominate over safety. Since 
the HTS study found that the presence of cargo capability with the human- 
tended vehicle has little effect on safety, and that other architectural consider- 
ations dominate, the amount of cargo capability in any next human trans- 
portation system should be predominantly driven by providing the trans- 
portation needs in an effective manner. (For the mission model used in this 
study, SSF resupply and logistic support was the largest driver of delivery and 
return requirements.) 

New Personnel Vehicles Derived from an ACRV - Do not base the decision 
as to what the future transportation system should be based on whether the 
ACRV function should be common with the primary transportation 
function, since the inclusion of an ACRV had negligible effect on the 
architecture attributes. Once the overall transportation architecture decision 
has been made, the decision as to whether an ACRV is even required, or 
whether its function should be provided by the basic transportation capability, 
would be determined by whether it produced a favorable impact on the 
primary system-level attributes. 

Areas of additional study - Redefine new technology programs in such as way 
as to support a go/no-go commitment for these approaches within a total 
transportation architectural context. While new technology solutions such as 
SSTO appear advantageous, the fidelity of the cost and technical data does not 
currently allow commitment to this alternative. For example, the SSTO 
requires further definition in ground processing turnaround to validate the 
costs relative to other transportation alternatives that have much better cost 
definition. (The HTS study results indicate that the total SSTO program costs, 
DDT&E, production, and operations, would have to increase by a factor of 
only 2.3 to negate any cost advantage over the Space Shuttle.) Redefining the 
early SSTO definition activities to obtain that data for comparison on an equal 
architectural basis would foster an early decision from among the trans- 
portation alternatives. This also holds true for NASP-derived vehicles, 
AMLS, and air-launched concepts with significant cargo capacity. 



SECTION 6 
SUMMARY 


The NIT arrangement proved to be an excellent forum for conducting this type of 
study. Bringing the combined analytical capabilities of industry and NASA to bear 
on a single objective yielded more thorough study results than could have been 
achieved otherwise. This approach also allowed the evaluation of more architec- 
ture and system options, to a greater level of detail, than could otherwise have been 
evaluated. One primary reason for this is because the team often had one or 
multiple "models", "tools", or "techniques" already available to it, which had been 
developed and refined with significant monetary investment. In fact, the tools 
available to us were in some cases better than our ability to use them in the 1 year 
available for this study. 

Although the industry team members each had vested interests in particular system 
concepts, this did not present a problem as long as the concepts were all passed 
through the same analytical process and reviewed by the entire NIT. In fact, this 
approach had the significant advantage of providing the built-in checks and balances 
that are often missing in studies conducted by single organizations, whether 
government or contractor. It was the consensus of all participants that this approach 
warrants more consideration for similar architectural evaluations. 
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